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A  design  for  a  secure,  multi-user.  File  Storage  System 
is  developed.  This  design,  incorporating  a  concurrently 
developed  Security  Kernel,  provides  a  multilevel  secure 
flexible  file  storage  serving  a  distributed  system  of 
dissimilar  computers.  The  Security  Kernel  is  resoonsible  for 
non-discreti or.ary  (e.g. ,  classification  and  clearance) 
security  and  the  File  Storage  System  Supervisor  is 
responsible  for  discretionary  (e.g..  need  to  know  ) 
security.  Multilevel  security  is  achieved  by  the  controlled 
access  to  consolidated  file  storage  for  Host  computer 
systems.  Multiprogramming  of  surrogate  Supervisor  processes 
operating  on  behalf  of  the  Host  computer  systems  provides 
for  system  efficiency.  A  segmented  memory  at  the  Supervisor 
level  allows  controlled  data  sharing  among  authorized  users. 
System  integrity  is  independent  of  the  internal  security 
controls  (or  lark  of  them)  in  the  distributed  systems:  the 
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data,  predicates  a  "star"  network  for  the  system  structure 
as  depicted  in  figure  1.  It  must  be  noted,  however,  that  the 
FSS  cannot  control  the  physical  security  of  the  Host  systems 
and  that  Host  systems  have  the  ability  to  circumvent  FSS 
security  by  direct  inter-Kost  communication  links.  To 
preserve  data  security,  all  accesses  to  the  FSS  consolidated 
data  must  go  through  the  FSS  for  access  validation. 

Bata  sharing  among  authorized  users  is  accomplished  by  a 
segmented  environment  which  allows  controlled  direct  access 
to  all  on-line  data.  The  Security  Kernel  (or  simply  Kernel) 
is  used  to  insure  that  nor-dis cretionary  data  access  is 
performed  ir.  an  absolutely  controlled  (i.e.,  secure)  manner. 
(See  [Coleman]  for  detailed  information  on  the  Security 
Kernel . ) 

A.  PROBLEM  DEFINITION 

"it  is  illogical  to  ignore  the  fact  that  computers  may 
disseminate  information  to  anyone  who  knows  how  tc  ask  for 
it,  completely  bypassing  the  expensive  controls  ulaced  on 
paper  circulation."  [Schell  (1)1 

That  this  fact,  is  ignored  is  demonstrated  by  the 
estimated  100  million  dollars  lost  yearly  by  non-secure 
computer  systems  in  the  United  States  [Der.ning(2 )]  .  It  is 
obvious  that  a  primary  problem/limitation  of  computer 
systems  in  use  today  is  the  lack  of  data  security.  As 
requirements  to  store  and  access  data  by  computer  increase, 
the  seriousness  of  this  problem/limitation  cannot  be 
ignored. 

A  system  that  can  simultaneously  provide  data  at 
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different  sensitivity  (viz.,  "classification")  levels  for 
users  with  different  access  authorizations  {viz., 
"clearances")  without  a  security  violation  is  said  to  be  a 
multilevel  secure  system.  Because  it  is  usually  not 
desirable  to  authorize  all  system  users  access  to  the 
highest  level  of  data  '’system  high')  or  provide  separate 
(without  sharing)  systems  f  *-r  each  level  of  data,  a 
multilevel  system  is  highly  desirable.  K  multilevel  system 
also  allows  the  maximum  amount  of  controlled  data  sharing 
among  authorized  users,  a  primary  goal  of  any  data  storage 
system. 

Previous  research  shows  that  a  viable  approach  to  the 
auestion  of  internal  computer  security  exists.  This 
approach,  sometimes  termed  the  "security  kernel  approach" 
[Schell^2)j,  was  introduced  by  Schell  in  1972.  It  gathers 
into  one  module  all  elements  that  effect  the  system 
security.  The  module,  by  being  restricted  in  size,  can  be 
verified  correct  which  in  turn  allows  the  total  system  to  be 
certifed  secure. 

The  FSS  software  is  composed  of  the  Supervisor  and  the 
Kernel.  It  will  provide  a  multilevel  secure  consolidated 
file  storage  for  distributed  Host  computer  systems.  The 
non-discretionary  security  provided  by  the  Kernel  and  the 
discretionary  security  provided  by  the  Supervisor  will 
implement  a  wide  range  of  security  policies,  including  the 
standard  Department  of  Defense  (DOD)  security  policies.  Data 
sharing  is  achieved  by  a  segmented  memory  environment  at  the 


Supervisor  level.  The  Supervisor  uses  segments  (invisible  to 
the  Host  systems)  to  construct  the  Host  files.  Multilevel 
security  is  achieved  by  the  management  of  files  submitted  by 
the  Host  systems  which  exist  at  distinct  security  levels. 
This  allows  the  construction  of  a  multilevel  secure  system 
which  is  dependent  cn  crly  one  secure  element  of  the 
FSS — the  Kernel. 

3.  BACKGROUND 

The  dramatic  reduction  in  size  and  cost  along  with  the 
increase  in  performance  of  microprocessors  ir<  the  last 
decade  has  made  their  use  feasible  in  areas  that  have 
previously  been  reserved  for  mini/maxi  computers  {or  r-ot 
computed  at  all).  Whereas  security  has  been  notoriously 
lacking  io  the  larger  systems,  it  has  been  nonexistent  in 
microprocessors  to  date. 

Because  of  their  small  size,  low  cost,  durability,  and, 
perhaps  most  importantly,  the  manpower  savings  induced  *'just 
to  mention  a  few  of  many  advantages),  microprocessors  have 
high  arpeal  for  use  in  a  military  environment.  However,  the 
military  also  has  an  obvious  need  for  security  within  their 
computer  systems,  whether  they  are  micro,  mini,  or  maxi 
based . 

For  example,  the-  Navy  is  presently  considering  systems 
for  the  next  generation  of  non-tactical  shipboard  computers 
[Smith!.  They  will  be  mainly  used  for  data  processing  in  the 
areas  of: 
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Pay  and  Personnel 
Supply  and  Finance 
Maintenance . 


Cost,  size  and  speed  constraints  will  soon  be  met  by 
commercially  available  products.  Security,  however, 
continues  to  be  a  problem  net  adeauately  addressed  in  any 
available  systems.  'To  preserve  data  confidentiality  (not 
only  with  respect  to  clearance  level  but.  also  with  respect 
to  the  current  stipulations  of  the  Privacy  Act),  security  is 
a  necessary  part  of  any  shipboard  computer  system.  Fay 
records,  for  example,  should  not  have  the  same  access  level 
as  maintenance  records.  In  order  to  store  records  in  a 
common  data  base  and  to  have  controlled  sharing  when 
appropriate,  the  computer  must  be  able  to  maintain  a 
multilevel  secure  environment. 

There  are  several  possible  approaches  to  achieve  a 
secure  multilevel  environment.  The  frontal  approach,  which 
is  most  difficult,  is  to  certify  all  distributed  computers 
which  have  access  to  the  data  base  as  secure,  k  second 
method  and  the  method  adopted  for  the  FSS,  is  to  cerfify 
only  one  element  of  the  FSS  secure — the  Security  Kernel.  All 
access  to  the  FSS  that  involves  non-discretionary  security 
will  be  validated  by  the  Kernel.  The  FSS  therefore 
guarantees  to  manage  files  in  a  manner  consistant  with  the 
FSS  security  policies. 

The  design  for  the  FSS  is  one  member  of  a  family  of 
systems  proposed  by  O'Connell  and  Richardson  [O'Connell] . 


Security,  configuration  independence,  and  a  loon-free 
structure  are  characteristics  of  this  family  of  systems. 

C.  BASIC  DFFI NIT IONS 

1 .  Securi tv 

4lthough  any  viable  secure  system  includes  both 
interna]  and  external  aspects,  relying  excessively  or 
externa]  controls  is  not  desirable  in  many  cases  due  to  the 
added  expenses  and  increased  security  risks  involved  in 
error-prone  manual  procedures.  External  controls  also  cannot 
provide  the  secure  sharing  of  data  that  is  needed  ir,  such 
applications  as  integrated  data  bases  and  computer  networks, 
primary  characteristics  of  the  FSS.  The  use  of  the  Kernel 
concept  is  a  demonstratively  effective  and  practical  method 
for  providing  the  internal  computer  security  controls  that 
are  necessary  for  a  secure  multilevel  system.  This  concept 
is  at  the  center  of  the  FSS  design. 

The  basic  concept  behind  this  approach  is  that  a 
small  portion  of  hardware/software,  the  Kernel,  can  provide 
the  internal  security  controls  that  are  effective  against 
all  attacks,  (malicious  or  accidental}  including  those  never 
thought  of  by  the  designer.  (This  also  means  that  errors  In 
the  FSS  Supervisor  cannot  cause  unauthorized  access  to 
data . ) 

System  security  is  the  implementation  of  a  security 
policy.  This  policy  is  a  collection  of  laws,  rules,  and 
regulations  that  establish  the  rules  for  access  to  the  data 
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in  the  system.  Such  policies,  such  as  the  one  established  by 
the  BOD.  have  two  distinct  aspects:  discretionary  and 
noR-discretionary  security.  Noa-discretionary  security 
externally  constrains  what  access  is  possible.  In  the  DOD 
environment,  the  familiar  non-discret ionary  security  levels 
are:  top  secret,  secret,  confidential,  and  unclassified. 
Since  most  contemporary  iputer  systems  do  not  provide  the 
data  labeling  reces  .  ry  t.o  support  non-discreti  onary 
security,  all  data  is  implicitly  accessible.  In  the  FSS, 
segmentation  allows  uninue  identification  and  labeling  of 
data;  nor— discretionary  security  is  therefore  supported.  The 
Kernel  is  the  one  element  in  the  FSS  responsible  for 
enforcing  non-di scretionary  security. 

Non-discretionary  security  involves  the  comparing  of 
the  access  class  of  a  specific  object  (object  access  class, 
(oac))  with  the  access  class  of  the  reauestor  (subject 
access  class,  (sec))  to  insure  compatibility.  In  a  DOD 
environment,  for  example,  a  person  (subject)  with  sac  of 
secret  has  access  to  files  'objects)  at  any  access  class 
equal  to  or  less  than  secret.  The  relationships  between 
different  access  classes  are  represented  by  a  partially 
ordered  lattice  structure  [Benningd)! .  This  lattice 
represents  the  authorized  access  based  on  the  relationships 
of  two  levels,  fi r  example  of  the  not-related  (making  the 
lattice  partially  ordered)  relationship,  occurs  because  of 
DOD  compartmental i zation  (e.g.,  secret  is  not  related  to 
secret. nuclear ) .  The  following  accesses  are  permitted  for 
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the  relationships  represented  by  this  lattice  structure. 

sac  =  oac  sreal/write  access 

sac  >  oac-  tread  access  (read  down' 

sac  <  oac  tWrite  access  (write  up) 

sac  O  oac  :no  access  (sac  not  related  to  oac) 

In  each  case,  the  Kernel  must  know  the 
identification  of  the  Host  system  if  it  is  to  perform 
correct  non-discretionary  security  checks.  Unique  system 
identification  is  provided  by  the  system  port  number,  which 
is  hardwired,  and  known  to  the  Kernel. 

Discretionary  security  provides  a  refinement  to  the 
non-discretionary  security  policy  and  is  reflected  in  the 
BOD  "need  to  know"  policy.  Computer  systems  which  have 
Access  Control  Lists  (ACL)  associated  with  data,  implement 
this  discretionary  policy.  The  FSS  Supervisor  is  responsible 
for  the  System  discretionary  security  and  although  this 
aspect  of  the  System  security  is  not  validated  by  the  Kernel 

(and  therefore  not  certified  correct),  the  validity  of  the 

0 

non-disc  t ionary  security  is  not  affected. 

*  implement  its  'aspect  of  security,  the  Supervisor 
needs  to  know  the  identification  of  the  Host  system  "user”. 
This  Host  system  user  identification  must  be  passed  to  the 
FSS  Supervisor  by  the  Host  system.  Since  an  insecure  Host 
system  cannot  be  trusted  to  pass  the  correct  information, 
the  user  identification  is  only  as  good  as  the  Host  system 
implementation,  (i.e,,  FSS  discretionary  security  is  only  as 


good  as  the  Host  System's  implementation  of  discretionary 
security.)  This  implementation  may  be  good  on  some  systems, 
(e.g.f  UNIX  [Morris])  but  non-existent  on  other  systems 
(e.g.»  CP/M  [Digital]}.  It  must  be  remembered  that  this  in 
no  way  affects  the  enforcement  of  the  non-discretionary 
security  by  the  Kernel. 

2.  Process 

a,  process  can  be  described  as  a  locus  of  execution. 
The  collection  of  locations  that  may  be  accessed  during  this 
execution  is  known  as  the  process'  address  space  [MadniCk]  . 
A  process  also  has  the  characteristic  that  it  may  be 
executed  in  parallel  with  other  processes,  enhancing  system 
efficiency  and  allowing  the  separation  of  tasks  into 
different  processes  for  design  clarity. 

The  FSS  has  two  processes  per  Host  system.  These  are 
ah  ihput/output  (10)  process  for  Supervisor  to  Host  data 
transfer  and  communication  and  a  file  management  (PM) 
process  that  controls  and  maintains  the  Supervisor  file 
structure.  Interprocess  communication  is  achieved  by  the  use 
of  eventcounts,  sequencers,  and  synchronization  primitives 
internal  to  the  Kernel  (described  later). 

3.  Segmentation 

Segmentation  allows  for  the  direct  addressing  Of  all 
system  on-line  information  end  the  application  of  access 
control  to  this  information.  Note  that  direct  addressing 
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does  not  mean  random  access  to  the  on-line  information.  On 
the  contrary,  access  to  segments  is  controlled  hy  explicit 
memory  management  calls  to  the  Kernel  to  swap  in/cut  a 
segment,  A  segment  can  he  defined  as  a  logical  grouping  of 
information  such  as  a  subroutine ,  procedure,  data  area,  or 
file.  Each  processes'  address  space  consists  of  a  collection 
of  segments.  In  a  segmented  environment,  all  address  space 
references  require  two  components,  a  segment  specifier  and 
ah  offset  within  that  segment.  Segmentation  is  used  to 
provide  the  Supervisor  domain  of  each  process  a  virtual 
memory  of  limited  size.  Segments,  as  mentioned  earlier,  are 
used  by  the  Supervisor  to  construct  the  Eost  files  which 
retain  the  attributes  of  segments  ' i . e . ,  access  control). 

4.  Mu Itiprogramming 

&  multi programmed  environment  is  one  in  which  more 
than  one  process  is  in  a  state  of  execution  at  the  same 
time.  These  processes  share  processor  time,  memory,  and 
other  resources  among  the  active  processes.  In  the  design 
for  the  75S,  the  Supervisor  processes  are  multi programmed  in 
an  asynhcroaous  manner  for  system  efficiency.  A 
multiprogramming  environment  allows  the  Host  systems  to 
operate  in  a  logically  parallel  manner  which  adds  to  System 
design  simplicity  and  clarity. 

5.  Protection  Domains 

One  of  the  key  elements  necessary  for  valid  Kernel 


implementation  is  the  isolation 


of  the  Kernel  from  all 
possible  outside  influences.  This  ran  he  -done  through  the 


use  of  protection  domains. 

Protection  domains  are  used  to  arrange  Process 
address  spaces  into  "rings"  iSchroederj  of  different 
privilege.  This  arrangement  is  a  hierarchical  structure  with 
the  most  privileged  domain  being  the  inner  roost  ring.  Figure 
2  represents  the  ring  organication  in  the  FS8. 

Protection  rings  may  he  created  by  either  hardware 
or  software.  Hardware  is  more  efficient  but  is  not 
commercially  available  in  microprocessor  devices  today.  Two 


state  devices  are  available,  however,  and  by  impleroenti: 


the  two  states  as  separate  rings  and  providing  for  software 
ring  crossing  rpeohanisiros ,  the  necessary  two  protection 
rings  can  be  created. 


D.  SYSfFH  RSQUIHEHsNTS 


There  are  no  fixed  hardware  reouirements  for  the 
implementation  of  the  FSS.  System  efficiency  does,  however, 
depend  on  an  appropriate  choice  of  hardware.  Two  basic 
hardware  features  that  are  felt  to  be  necessary  for  a  viable 
implementation  of  the  FSS  are  segmentation  and  multiple 
domains. 

Segmentation  is  necessary  for  access  control  and  data 
sharing.  P.  multiple  state  (two  in  this  case)  is  necessary 
for  the  isolation  of  the  Kernel  from  the  remaining  (and 
uncertified)  softvare. 
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simplifies  Kernel  design  and  contributes  to  keeping  lemel 
size  small.  ft  seaweat  address  consists  of  a  segrer.I  Dane  and. 
offset  within  the  segment.  Although  this  addressing  can  be 
done  in  software,  it  is  faster  and  more  efficient  when  dons 
in  hardware.  Hardware  can  also  simultaneously  check  for 
authorized  access,  a  necessary  feature  of  a  secure  systen. 


Multiple  dopaius  ai 


t  V/  ■R^pJ 


larger  Machines  to  protect  the  operating  systems  from  to# 
applications  progress.  Multiple  domains  have  act.  natil 
recently,  heen  available  in  a  microprocessor  coBflsaritloB* 
The  ?SS  design  rsouires  only  two  Jowiis,  one  for  the  lerael 
and  one  for  the  Supervisor, 


"he  introduction  of  the  Ziloe  ZMf®  series 


ilerourocessor  rests  bo 


th  the  segmentation  and  naltiple 


domain  recnireBents,  The  F3S  is  targeted  for  inpleaeatatioa 
on  the  ZSCfl  seewented  microprocessor  |ZilogC2)l  with  its 
associated  ffenory  Management  Bait  { tWJ  [Hiogllll.  the 
IBSfli  is  a  16  bit  two-domain  machine  which  produces  a  S3  bit 


logical  address.  The  ZQ010  MMU  maps  the  23  hit  logical 
address  into  a  24  hit  absolute  address  and  allows  the 
capability  of  addressing  up  to  128  segments  (with  two  MMU's) 
of  64K  bytes  each  (8M-bytes  total)  in  a  two-dimensional 
memory  space.  (See  [Coleman]  for  further  details.)  RS-232 
bus  compatibility  is  assumed  for  serial  data  input/output  at 
the  hardware  level.  This  allows  byte  synchronization  and 
byte  parity  checks  to  be  performed  at  the  hardware  level  by 
the  ESS  universal  asynchronous  receiver-transmitter  (UART). 

3.  SYSTEM  STRUCTURE 

1  •  System  levels 

Abstraction  is  a  way  of  avoiding  complexity  and  a 
mental  tool  for  approaching  complex  problems  [Bi jkstra(2)] . 
The  use  of  abstaction  allows  the  presentation  of  a  system 
design  that  is  concise,  precise,  and  easy  to  understand. 
There  are  four  levels  of  abstraction  for  the  FSS  as 
presented  in  figure  3. 

Level  0  is  the  hardware  level  and  consists  of  the 
Z8001  microprocessor  memory  and  some  form  of'  disc  storage 
(initial  implementation  may  be  with  floppy  disc). 

Level  1,  the  Kernel,  is  isolated  and  protected  from 
manipulation  (accidentlal  or  malicious)  by  being  placed  in 
the  more  privileged  domain  of  the  Z8001.  Only  the  Kernel  has 
access  to  "system"  machine  instructions  and  controls  all 
access  to  the  system  hardware  elements  (memory,  disc).  The 
Kernel  provides  a  segmented  environment  in  which  the 
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Supervisor  operates. 

level  2,  the  Supervisor,  operates  in  the  outer  (less 
privileged)  domain  of  thi  Z8001 .  It  has  access  to  "normal" 
machine  instructions,  tut  must  go  through  the  software 
Gatekeeper  [Coleman]  of  the  Kernel  to  get  access  to  memory 
(viz.,  segments)  and  disc  storage.  The  Supervisor  provides  a 
virtual  file  hierarchy  to  each  Host  system  for  file-  storage. 
In  order  to  manage  the  file  hierarchy,  surrogate  processes 
(-input/output  (10)  and  file  management  (FM))  are  assigned  to 
each  Host  system.  These  processes  act  on  the  reauests 

submitted  by  the  Host  computer  systems.  All  processes  -are 

$ 

created  at  system  generation  time  and  are  not  created  or 
deleted  in  a  dynamic  manner. 

Level  3  consists  of  the  Host  computer  systems.  These 
systems  are  hardwired  to  the  Z8001  in  the  FSS  design,  lach 
port  has  a  fixed  access  level  so  that  if  a  multilevel  secure 
Host  desires  to  handle  data  at  two  levels,  it  must  have  two 
connections  to  the  FSS.  (Note  that  if  the  Host  is  not  a  true 
secure  multilevel  Host,  and  does  have  multiple  connections 
with  distinct  levels,  then  the  FSS  security  constraints  are 
circumvented . ) 

2.  System  Protocol 

Protocols  are  formal  specifications  which  constrain 
data  exchange  between  systems  and  the  FSS.  These 
specifications  allow  the  FSS  to  achieve  hounded,  deadlock 
free  and  fault  tolerant  communication.  To  organise  and 
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Simplify  protocol  design  in  the  FSS ,  protocol  is  logically 
divided  into  a  hierarchical  structure  of  two  interacting 
layers,  level  1  protocol  handles  packet  (described  later) 
'synchronization,  error  detection,  and  command  type 
determination*.  Level  2  handles'  the  repetitive  activity  of 
data  transfer. 

Data  and  commands  are  transmitted  between  FSS  and 
Host  via  fixed  size  packets.  Packet  synchronization  is; 
necessary  for  Host-FSS  communication.  Error 
detection/correction  is  closely  related  tc  the  -problem  ,of 
packet  synchronization*  packets  not  in  synchronization  will 
not  be  correct.  The  converse  is,  not  true,  however.  A 
synchronized  packet  may  contain  transmission  errors.  There 
are  several  methods  for  error  detection/correction 
[Hamming].  A  design  choice  of  a  simple  check  sum  per  packet 
(to  detect  packet  errors)  was  made  in  the  interest  of  System 
simplicity.  If  an  error  is  detected  in  a  packet,  the  Host 
will  be  requested  to  Stop  packet  transmission  and  to  begin 
again  with  the  packet  in  which  the  error  was  detected.  Of 
course,  the  FSS  must  be  able  to  provide  the  same  service. 
This  retransmission  upon  error  detection  strategy,  combined 
with  the  byte  parity  checks  performed  at  the  hardware  level 
by  the  UAHT,  will  provide  the  error  detection/correction 
scheme  in  the  initial  FSS  design. 

3.  Host  Environment 

The  job  of  the  FSS  is  to  provide  a  service,  viz,,  to 


store  files  in  a  secure  'data  warehouse*.  The  files  are 
submitted  by  various  Host  computer  ''stems.  The  virtual 
environment  provided  the  Host  systems  is  therefore  a  primary 
design  consideration  of  the  overall  FSS  design.  Design  goals 
are  to  make  this  Host  environment  simple,  easy  to  use  and 
understand,  efficient  and  robust. 

The  center  of  the  Host  environment  is  the 
hierarchical  file  structure  maintained  by  the  Supervisor  of 
the  FSS.  This  file  structure  is  a  tree  organization  which 
facilitates  design  abstraction  (virtual  file  systems  per 
Host)  as  well  as  file  system  searches  via  tree  traversal. 
Figure  4  illustra‘es  the  overall  logical  structure  of  the 
Supervisor  file  system. 

A  file  can  be  defined,  in  the  case  of  the  FSS,  as 
one  or  more  Supervisor  segments  grouped  together-  for  the 
purpose  of  access  control  f security),  retrieval  (read),  and 
modification  (write)  [Shaw].  In  the  FSS  the  file  is  the 
basic  unit  of  storage  at  the  Host  system  level. 

The  hierarchical  file  system  contains  two  types  of 
files?  1)  data  files,  and  2)  directory  files.  Both  file 
types  are  constructed  from  segments  (invisible  to  the  Host 
systems)  at  the  Supervisor  level.  The  characteristics 
usually  associated  with  a  segmented  environment  (Supervisor 
level)  such  as  data  sharing  and  access  control,  are 
transferred  to  the  file  environment  (Host  level)  by  the  FSS. 

The  Host  system  environment  consists  of  a  virtual 
file  hierarchy  maintained  for  each  Host  system  (i.e.,  ore 
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virtual  file  system  per  hardware  port),  A  primary  reason  for 
having  multiple  virtual  file  hierarchies  is  to  avoid  the 
problem  of  naming  cooficts  which  would  eventually  occur  in 
the  Supervisor  hierarchy  as  the  system  grew  if  per-host 
virtual  file  systems  did  not  exist.  Multiple  directories 
also  allow  the  Host  systems  to  group  related  files  into  one 
directory,  simplifying  search  and  Host  use.  The  Supervisor 
will  control  the  duplication  problem  within  a  virtual  file 
system  by  not  allowing  duplicate  file  names  in  a  single 
directory  file.  Pathnames  are  required  to  uniquely  identify 
files  in  the  Supervisor  file  systems  and  must  be  included  in 
the  Host  request. 

Access  to  the  Supervisor  file  hierarchy  is 
controlled  in  both  a  discretionary  and  non-discretionary 
manner.  The  non-discretionary  access  is  controlled  by  the 
Kernel  which  will  prevent  a  Host  system  from  reading  up  or 
writing  down  (confinement  property).  Discretionary  access  tc 
the  files  is  handled  by  the  Supervisor  which  compares  the 
Host.user  (Host  user  combination)  with  the  file  ACL. 
Requested  access  is  permitted  only  if  the  Host. user,  is 
explicitly  permitted  access  by  the  file  ACL. 

Kach  Host  system  virtual  file  hierarchy  is 
constructed  from  data  files  and  directory  files  which,  as 
mentioned  above,  are  constructed  of  Supervisor  segments. 
Although  dynamic  growth  and  shrinkage  are  usual  segment 
attributes,  a  design  choice  for  System  simplification  was 
made  to  fix  segment  size  at  three  increments,  SMALL  (512 
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bytes),  MEDIUM  (2E  bytes) ,  and  LAHGE  (8K  bytes).  These  sizes 
were  chosen  as  a  compromise  between  expected  file  sizes, 
supervisor  buffer  requirements ,  and  minimizing  the  number  of 
software  ring  crossings  that  would  be  required  during  a  data 
file  "read"  or  "store"  operation.  Because  segment  size  is 
limited  and  there  exists  the  likelihood  of  encountering 
files  larger  than  the  maximum  segment  size,  the  concept  of  a 
multiple  segment  file  (msf)  is  known  to  the  Supervisor. 

Figure  5  depicts  the  general  tree  structure  of  a 
Supervisor  virtual  file  hierarchy.  Directory  riles  are 
represented  by  squares  and  data  files  by  circles.  Data 
*  files,  as  their  name  implies,  contain  data  only.  Directory 
filet  are  constructed  of  a  header  and  zero  or  more 
"entries".  There  are  two  types  of  entries,  branch  entries 
and  link  entries. 

Branch  entries  contain  the  attributes  of  the  file 
which  they  identify.  In  figure  5,  for  example,  the 
-attributes  of  directory  file  User_l  -(entry  name,  ACL,  size, 
type,  etc.)  are  contained  in  directory  file  Host_l,  branch 
entry  User_l.  One  branch  entry  designates  one  Supervisor 


segment. 

a 

link  entry. 

represented 

by  the  dotted  line  in 

figure  5, 

is  composed  of 

an  "entry  na 

me"  (link  name)  and  a 

pa  thname . 

( A  pa  thname 

is  the  conca 

tenation  of  entry  names 

starting 

from  the  root 

directory 

and  proceeding  in 

sequential  order  to  the  specified  file.)  Like  a  branch 
.  entry,  a  link  entry  is  used  to  access  a  specific  file#  For 
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example,  in  figure  5,  the  pathname  contained  in  the  link 
entry  is  Kosti_l>User>-3>Biri_l .  Unlike  a  branch  entry, 
however,  the  link  entry  does  not  contain  any  file 
attributes.  Access  is  controlled  as  the  Supervisor  traverses 
the  specified  path  to  the  requested  file* 

The  use  of  link  entries  allows  sharing  of  files 
among  Host  systems  and  among  Host  system  users .  Loops  which 
might  be  generated  by  two  links  which  reference  each  other, 
are  prevented  by  the  Supervisor.  (Loops  could  present  a  tree 
traversal  problem  to  the  Supervisor.) 

Each  file  has  a  file  name  (Entry^Name — uniaue  per 
directory  file)  given  by  the  Host  system  at  file  creation 
time.  This  file  name  and  its  pathname  are  used  to  uri curly 
locate  the  file  in  the  Host's  virtual  file  system.  By 
traversing  the  virtual  hierarchy,  the  Supervisor  can  locate 
the  requested  file  if  it  exists  In  the  system.  In  either 
case  (viz.,  whether  the  file  exists  or  not),  appropriate 
action  can  be  taken  by  the  Supervisor. 

a.  Directory  File 

Figure  6  is  a  logical  representation  of  a  file 
directory.  Each  directory  file  is  made  up  of  a  header  and 
zero  or  more  fixed  size  branch /link  entries.  A  fixed 
directory  size  of  LARGE  (8E  bytes)  was  chosen  to  insure  a 
reasonalble  amount  of  directory  space  for  Host  system  use. 
This  could  pose  a  "space"  problem,  especially  for  secondary 
storage,  (Adequate  main  memory  can  be  installed  for  required 


Birectory  file 


(Header  5 

!ntry_Count-l  'byte 
SCI  Count-2  bytes 


(3ranch  Entry) 
intry_Nine-18  bytes 
5raRCh_Link_Switch-i  byte 
A0L_Ptr-2  bytes 
Tile  Size— 4  bytes 
Data“Bir_Svi tch-1  byte 
-rile_C reeled — 16  bytes 
last* Updater-16  bytes 
Access  Class-1  byte 


( Link  JEn try) 

Brtry_Maine-i8  bytes 
Branch_iink_Switcb-l  byte 
Link-128  bytes 
Link  Created-16  bytes 


figure  6.  Logical  Directory  St 
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buffer  space.)  The  Kernel,  which  stores  segments  as  pages, 
ftjay  want  to  'compact''  segments  by  not  storing  on  secondary 
storage  pages  which  contain  all  "teros".  This  would  greatly 
reduce  the  amount  of  wasted  space  on  secondary  storage. 
(Another  equally  viable  solution,  hut  not  selected  for  tms 
deSi2n(  is  to  have  multiple  segment  directories  in  the 
Supervisor  similar  to  multiple  segment  aata  fi-.es. i 
directory  file  header  contains  the  following  informations 

nnu«tt  This  is  the  number  of  branch  '’link 

entries  in  the  directory. 

ACL  Count:  This  is  a  count  of  the  number  os 

*CX.  INTET  elements  left  in  a  "pool"  of  such  elements, 

t f  the  entry  is  a  branch  entry,  it  will  contain 

*%» 

the  following  elements: 

Intry  Maine:  Tntry  name  is  the  file  name.  *  — 
Host  systems  are  responsible  for  supplying  these  names  h«-., 
as  mentioned  above,  will  be  prevented  by  the  Sopevisor  from 
having  duplicate  names  (file  names)  in  one  directory  file. 

Aecess_Class:  This  element  contains  the  file 

access  level. 

3ranch_Link_Switch:  This  element  will  identify 
the  entry  as  a  branch  entry  which  in  turn  specifies  the 

entry  format . 

A0T,  Ptr:  This  element  will  point  to  an  bCi»  *or 
the  branch  entry.  the  fSS  has  only  three  distinct 
discretionary  access  modes:  l)  null  access  as  3  e 

implies,  declares  that  no  access  is  to  be  allowed  to  vne 


. . Ill . . .  ft  -  “MW . . . . . . . (I . 

SLhazM&j&kl  Mirths  &  «,w  j«..uIlL  t  vjikux*  Ai.- . . .  . lit  'Ll-,  .,i. 


specified  lost .user  coaMnation,  2)  "read*  access  allows 


Qualified  lost. user 


read  a 


Le  only  Ci 


no  writi 


access},  3)  vri le”  access  allows  a  lost. user  write  access 
a  fau0  read  access).  The  actual  nci  will 

be  a  list  of  authorized  users  in  the  form  Host. user  with  at* 


associated  access 


Le.  fi  don't  care 


horization 


this  case  a  ,  will  allow  seneral  access  in  that  category. 


For  example,  *.uSer  would  allow 
access  this  file  from  any  connected 
specified  access  roode.  This  =€L  for  i 


specified  user  to 


>st  system  wito  a 


entry  user  can  easiij 


he  expanded  to  include  other  categories  such  as  project  to 


further  refine  the  discretionary  access  allowed  %% 


«  P-j  1  =-t 

CI 


File_Si*e;  This  information  is  necessary  for 
proper  management  of  the  lost  K£At*_FIlE  and  STQiSJffLI 
commands  by  the  Supervisor,  viz. .  it  allows  the  Supervisor 
to  calculate  the  number  of  seeneBts  that  male  up  a  multiple 
segment  file.  It  will  he  supplied  by  the  lost  system  in  the 


ST0R1  fill  command  reouest  'is  bits). 


)ata  Bif  Switch: 


tch  tells  the 


Supervisor  the  type  of  file  to  which  the  branch  points 
f data,  directory).  This  is  necessary  due  to  the  different 


file  formats. 


file  Created;  This  element  is  used  fcr 


audit  purposes,  l.e»«  to  have  a  permanent  record  of  the  fils 
creator  and  the  time  of  creation. 

last  Opiate:  This  element  will  identify  the  las' 


Host  afd  user 


store  into  the  file.  This  identification 


will  be  of  the  form  lost. user, date. time,  this  will  allow  the 
J5S  to  have  a  limited  audit  capability,  the  confinement 
otopertv  ureverts  the  ?SS  fron  also  keeping  track  of  read 


accesses  since  processes  at  higher  levels 


in  reaa  at 


levels  bat  cai 


write  the  audit  isfotwatioo. 


that  the  Last_Bpdate  information  for  » 
oav  not  be  accurate  for  the  same  reason. 


If  the  entry  is  a  link 


four  elements.  These  arfi:  li  Entry  Maw 


ungraded  directories 


contains  only 


uoentixy 


file.  2) 


ranch  link  Swl 


tn 


identify  the  entry  tyoe,  3) 


link,  a  oathname 


uniquely  identify  a  file,  and  4] 


CreateJTiae*  the  tide  of  link  initiation  along  with  the 
lost. user  vhn  created  the  link*  ill  attribute  checking  Is 
done  as  the  Supervisor  traverses  the  specified  path. 

A  TSS  design  choice  is  to  limit  all  hathleiigths 
to  126  bytes.  This  places  sow#  restrictions  on  the  Host  ill 
that  long  file  oases  will  sooi!  consume  the  bytes  available 


for  a  rathnase.  However,  this  restriction  can 


overcome  by 


pathnames  which  contain  several  link  entries,  which  can 
themselves  be  128  bytes,  with  32  bran eh/1 ink  entries  per 
directory,  there  are  an  average  of  32  ACL  entries  (3  bytes 
each)  available  to  each  branch  entry.  Ctesewber.link  entries 
do  cot  have  ACL-  entries.)  Figure  6  contains  the  initial 


field  sires  for  the  directory  construction.  The  primary 
factor  in  calculating  the  sire  of  branch/lial  entries  is  the 
sire  of  the  link  pathname,  this  increases  the  siie  of  link 


entries  to  163  bytes  and  altboueh  space  is  vested  it*  branch 


entries,  the  simplification  of  System  design  resulting  from 
a  fixed  size  of  branch/3ink  entry  is  felt  to  he  sufficient 
justification  in  the  initial  design. 

t.  Data  Tiles 

Data  files  are  always  "leaf"  nodes  in  the  file 
hierarchy  and  contain  only  data. 

c.  Multiple  Segment  Tile  Directory 

A  msf  directory  is  a  Supervisor  construct 
(invisible  to  Host  systems)  to  manage  files  larger  than  the 
maximum  fixed  segment  size.  Because  the  number  of  segments 
that  will  be  required  by  the  Supervisor  to  store  a  file  can 
be  calculated  from  the  file  size  information  passed  by  t.ie 
Host,  a  msf  directory  need  only  be  a  segment  of  size  zero. 
This  makes  the  Kernel  alias  table  (which  is  a  fixed 
size — see  [Coleman])  the  limiting  factor  in  the  maximum  file 
size.  The  alias  table  has  the  same  number  of  entries  as  a 
Supervisor  directory  fviz.,  32)  which  limits  maximum  Host 
file  size  to  256K  bytes.  Files  that  exceed  the  maximum  file 
size  must  be  split  by  the  Host  system.  An  attempt  to  store  a 
file  that  is  ’too'  large  will  result  is  an  error  condition 
response  to  the  Host  and  an  unexecuted  command. 

4.  Host  System  Commands 

The  Host  commands  provide  the  only  interface  that  a 
Host  system  has  with  the  FSS.  Each  command  is  interpreted  by 
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the  FSS  and  acted  upon  hy  surrogate  Supervisor  processes? 
the  Host  system  has  no  direct  access  to  the  FSS.  There  is 
one  acknowledgement  between  the  Host  and  FSS  at  this  level. 
This  is  a  "command  complete"  acknowledgement  that  informs 
the  Host  system  that  the  Supervisor  has  completed  action  on 
its  request.  If  an  error  condition  occurs,  the  appropriate 
error  code  is  returned  in  the  acknowledgement. 

Another  aspect  of  the  Host  environment  needs  to  be 
defined  alsc.  The  Host  environment  can  be  divided  into  two 
states?  they  are  the  “old"  state,  before  the  FSS  has  acted 
upon  the  Host  request,  and  the  "new"  state,  which  occurs 
after  action  has  been  completed  by  the  FSS.  The  specific 
state  of  the  FSS  at  any  instant  is  indeterminate  at  the  Host 
level  if  more  than  one  Host  is  accessing  the  same  file  of 
the  FSS  at  one  time.  That  is,  since  Supervisor  processes 
execute  in  a  completely  asynchronous  manner,  the  FSS  state 
may  change  after  a  Host  command  is  sent  but  before  the  FSS 
acts  cn  the  command.  This  will  not  affect  the  performance  of 
the  System  or  validity  of  its  security?  Host  commands  will 
be  executed  as  a  single,  atomic  operation  in  the  FSS  state 
in  which  they  are  received  and  interpreted.  The  Host  will 
get  some  "correct"  response  for  some  state  existing  between 
the  sending  of  the  Host  conmand  and  the  FSS  acknowledgement 
on  the  same  command.  This  allows  several  Hosts  to  safely 
synchronize  their  actions  external  to  the  FSS. 

The  following  is  considered  to  be  a  minimal  subset 
of  commands  available  to  the  Host  System  for  adeouate  file 
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control.  Figure  7  illustrates  the  required  discretionary 
access  attributes.  The  files  are  referenced  in  the  Host 
command  descriptions  starting  from  the  root  of  the  Host 
virtual  file  system.  The  pathname  specifies  the  parent 
directory  file  (containing  access  attributes  of  the  file), 
and  the  file  (data  or  directory)  to  which  the  Host  command 
refers.  All  commands  require  a  pathname  for  unique  file 
identification.  Fach  command  also  requires  the  specification 
of  the  Host  system  "user"  in  order  for  the  Supervisor  to 
perform  discretionary  security  checks.  This  'userid"  will  be 
supplied  by  the  Host  system  or  the  Host  system  user,  which 
ever  is  appropriate. 

CREATE_FILE  <pathname,  access_class ,  file_type 
(directory,  data)>.  This  command  reauests  that,  the 
Supervisor  create  a  branch  entry  in  the  specified  directory 
under  the  specified  file  name  at  the  specified  access  class. 
An  initial  access  mode  of  write  will  be  given  to  file 
creator  and  may  be  altered  by  the  use  of  the  ADD_ACLJENTRY 
and  DELETE_ACL_ENTEY  commands.  This  is  the  only  Host  command 
where  file  access  class  is  specified.  It  is  used  in  this 
command  to  create  upgraded  directory  files,  if  desired. 
(Data  files  may  not  he  upgraded — described  later.)  In  the 
initial  implementation  (with  single  level  Hosts),  there  will 
he  no  upgraded  directories  within  a  Host  virtual  file 
system.  Initial  data  file  size  is  zero;  initial  directory 
file  size  is  LARGE  (8K  bytes).  Actions  taken: 

1)  The  Supervisor  locates  the  root  of  the  virtual 
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Figure  7.  File  Discretionary  Access  Control 
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file  system  for  this  Host  and  does  a  tree  traversal  to 
locate  the  parent  directory  file. 


2}  If  the  parent  directory  file  is  not  found  or 
found  hut  write  access  to  the  parent  directory  file  is  not 
allowed,  an  appropriate  error  code  is  returned  ("file  not 
found'  or  'write  not  permitted’), 

3)  If  the  directory  file  is  found,  and  room  exists 
in  the  directory,  the  new  file  is  entered  in  a  branch.  As 
mentioned  above,  no  duplicate  file  names  will  he  allowed  hy 
the  Supervisor. 


CRSATE_LINK  <pathname,  link  ,userid>.  This  command 
reouests  that  the  Supervisor  create  a  link  in  the  specified 
directory  under  the  specified  file  name.  As  already 
mentioned,  the  Supervisor  will  not  allow  links  to  form 
loops.  This  is  done  hy  restricting  the  maximum  number  of 
files  in  one  pathname  to  64  files.  (This  figure  is  reached 
hy  allowing  a  maximum  pathlength  of  128  bytes  and  having 
file  names  of  one  character.  Pile  name  delimiters  of  one 
character,  viz.  will  give  a  maximum  pathlength  of  64 
files.)  3y  keeping  track  of  the  path  traversed,  the 
Supervisor  is  able  to  determine  if  and  when  a  loop  is 
formed.  Actions  taker.: 

1)  The  Supervisor  locates  the  root  of  the  virtual 
file  system  for  this  Host  and  does  a  tree  traversal  to 
locate  the  parent  directory  file. 

2)  If  the  parent  directory  file  is  not  found  or 
found  hut  write  access  to  the  parent  directory  file  is  not 
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allowed,  an  appropriate  error  code  is  returned. 


3)  if  the  parent  directory  file  is  found  and  room 
exists  in  the  directory,  the  link  is  entered  in  a  link 
entry . 


DELETE_FILE  <patkname  .userid>.  This  command 
reauests  that  the  Supervisor  delete  the  specified  file  from 
the  virtual  file  hierarchy.  For  design  simplicity,  only 
terminal  files  (including  msf's),  can  he  deleted.  This  means 
that  directories  must  be  empty  in  order  to  be  deleted. 
Actions  taken: 

1)  The  Supervisor  locates  the  root  of  the  virtual 
file  system  for  this  Host  and  does  a  tree  traversal  to 
locate  the  parent  directory  file. 

2)  If  parent  directory  file  is  not  fojnd  or  found 
hut  write  access  to  the  parent  directory  file  is  not 
permitted,  an  appropriate  error  code  is  returned. 

3)  Otherwise,  if  the  file  is  located,  it  is  deleted 
by  the  Supervisor. 

REAB_FIL!  <pathname,  command_type (directory,  data, 
size)  ,userid>.  This  command  reauests  that  the  Supervisor 
transmit  to  the  Host  either  a  data  file,  directory  file 
(selected  elements  only),  or  the  ?ile_Size,  Last_Update,  and 
Access_Class  (entry  data)  elements  associated  with  a 
particular  file.  An  explanation  of  the  last  parameter,  tc 
transmit  entry  data  only,  needs  some  explanation. 

Branch  entry  elements  can  be  logically  divided  into 
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two  categories  with  respect  to  discretionary  security.  The 
first  category,  which  includes  Entryjiame, 
Branch_Link_Svitch,  Access_Class ,  and  AClJPtr  are  branch 
entry  attributes  which  cannot  be  altered  by  a  Host  process 
unless  the  process  has  discretionary  write  access  to  the 
directory  which  contains  the  file  branch  entry. 

The  second  category,  which  contains  File_5ize  and 
Last_Update,  are  attributes  which  'belong*  to  the  file  and 
must  be  updated  when  the  file  is  updated.  A  situation  may 
exist  where  a  process  may  not  have  any  discretionary  access 
to  a  directory  but  may  have  discretionary  read  access  to  a 
file  in  the  directory  (plus  implicit  access  to  the  rest  of 
the  directory  during  the  "search").  In  order  to  read  this 
file,  the  Host  system  will  need  to  know  file  size  in  order 
to  prepare  to  receive  it.  This  is  the  situation  where  the 
?.EAD_FILE  (size)  command  is  needed.  Actions  taken:  (for  data 
file) 

1)  The  Supervisor  locates  the  root  of  the  virtual 
file  system  for  this  Host  and  does  a  tree  traversal  to 
locate  the  desired  directory  file, 

2)  If  the  file  is  not  found  or  found  hut  read  access 
to  the  file  is  not  allowed,  an  appropriate  error  message  is 
returned . 

3)  Otherwise,  the  file  is  transmitted  to  the 
reauesting  Host  System. 

(for  directory  file) 


2)  Same. 

3)  If  the  directory  file  is  found  and  read  access 
allowed,  selected  elements  of  the  tranch/link  entries  are 
returned  to  the  Host. 

(for  file  size) 

1)  The  Supervisor  locates  the  root  of  the  virtual 
file  system  for  this  Host  •;-.4  does  a  tree  traversal  to 
locate  the  desired  file. 

2)  If  the  file  is  not  found  or  found  hut  read  access 
to  the  file  is  not  permitted,  an  appropriate  error  code  is 
returned. 

3)  Otherwise,  the  File_Size  and  Iast_Upd6te  elements 
are  returned  to  the  Host. 

STCR?_?ILE  <pathname,  file_size  ,userid>.  This 
command  reauests  that  the  supervisor  store  the  specified 
file  in  the  ESS.  Actions  taken: 

1)  The  Supervisor  locates  the  root  of  the  virtual 
file  system  for  this  Host  and  does  a  tree  traversal  to 
locate  the  data  file. 

2)  If  the  data  file  is  not  found  or  found  tut  write 
access  to  the  data  file  not  allowed,  an  appropriate  error 
code  is  returned.  Note  that  Host  systems  can  store  only  data 
files!  directories  are  ’built'*  by  the  Supervisor. 

3)  Otherwise,  a  store  operation  is  performed  by  the 

FSS . 

REAfACL  <pathname  ,userid>.  This  command  is  used  by 
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the  Eost  systems  in  conjunction  with  the  ABB_ACL_ENTRY  and 
BEt5TE_nCJ._E.NTEY  to  adjust  {give/rescind )  the  access  mode 
(read/write)  allowed  to  a  Host/Host  user  to  a  specific  file. 
Actions  taken: 

1)  The  Supervisor  locates  the  the  root  of  the 
virtual  file  system  for  this  Host  and  does  a  tree  traversal 
to  locate  the  parent  directory  file. 

2)  If  the  file  is  not  found  or  is  found  hut  read 
access  is  not  allowed  to  the  parent  directory  file,  an 
appropriate  error  code  is  returned. 

3)  Otherwise,  the  supervisor  returns  the  file  ACL 
for  Host  system  user  examination. 


ADD_ACL_ENTRY  <pathname,  ACL_3ntry  ,userid>.  This 
command  reauests  the  Supervisor  to  add  to  the  specified  file 
ACL  the  specified  ACL_Entry  (Host. user  combination  plus 
associated  access  mode).  As  with  the  previous  commands*  the 
access  is  checked  for  correctness  by  both  the  Supervisor  and 
the  Kernel  before  any  action  is  taken. 


DEL  E  TE  _  A  C  L_S  N  T  E  Y  pathname,  ACL_Entry  ,userid>.  This 
command  reauests  that  an  ACL_Entry  be  deleted  from  a  file 
ACL.  Again,  appropriate  discretionary  and  non-discretianary 
checks  are  made  before  any  action  is  taken  by  the  ESS. 


ABORT.  This  command  reauests  the  Supervisor  to  quit 
execution  of  the  present  command  and  return  the  file  system 
to  its  original  state.  There  are  only  certain  locations  in 
the  execution  of  Host  commands  that  the  Supervisor  is  able 
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to  interupt.  If  an  ABORT  command  is  received  after  an 
operation  has  teen  completed  tut  before  the  final  Host 
acknowledgement  is  sent,  the  original  command  completion 
will  be  acknowledged  and  the  abort  command  will  te  ignored. 
Otherwise,  action  of  the  command  will  be  halted  and  the 
Supervisor  will  wait  for  another  Host  command.  All  Host 
commands  (including  ABOUT )  will  be  explicitly  acknowledged 
with  either  a  "command  complete  message  or  an  appropriate 
error  code. 

C.  PROCESS  STRUCTURE 

fhere  are  two  Supervisor  processes  which  act  on  behalf 
of  each  Host  system  (hardware  port).  The  input/output  (10) 
process  and  the  file  management  (EM)  process.  The  10  process 
is  responsible  for  communication  and  data  transfer  (via 
packets)  between  the  Supervisor  and  the  Host  system.  The  Eh 
process  is  responsible  for  managing  the  per— Host  virtual 
file  systems  and  providing  overall  ESS  control.  All  nost 
commands  are  interpreted  by  the  FM  process;  the  10  process 
Q£p5  in  a  "slave  mode  to  the  TM  process.  Acting  together, 
the  EM  and  10  processes  interpret  and  execute  the  file 
management  requests  of  the  Host  systems.  Kernel  primitives 
EEAB.  ADVANCE.  AWAIT,  and  TIGHT  used  in  conjunction  with 
eventceunts  and  sequencer  (described  later),  are  used  to 
synchronize  Host  surrogate  process  execution. 

Both  the  EM  and  10  processes  call  on  Kernel  primitives 
to  perform  actual  segment  manipulation.  Tre  normal  order  m 
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which  these  calls  are  made  is  fixed  by  the  Kernel  design.  To 
add  a  segment  to  a  process  memory,  the  order  of  Kernel  calls 
is:  1)  Gatekeeper. Create_5egment ,  2}  Gatekeeper. Make  Jlaovn, 
and  3)  Gatekeeper .Swap_In .  To  delete  a  segment  from  a 
process  memory,  the  order  of  Kernel  calls  is:  1) 
Gatekeeper .Svap_Qut,  2}  Gatekeeper. Terminate,  and  3) 
Gatekeeper .Belete_Segment .  The  Supervisor  procedures  use 
these  invocation  orders. 

There  are  three  levels  of  abstraction  for  a  Host 
surrogate  process.  They  are*  1)  the  level  at  which  Host 
commands  are  known.  2)  the  level  at  which  files  are  known, 
and  3)  the  level  at  which  Supervisor  segments  or  packets  are 
known.  These  levels  of  abstraction  should  be  kept  in  mind 
when  reading  the  TM  and  10  process  descriptions. 

A  design  choice  to  simplify  file  system  maintenance  and 
control  is  to  allow  upgrading  of  only  directories  (e.g., 
unclassified  to  secret).  This  will  eliminate  the  possibility 
of  having  a  secret  file  in  an  unclassified  directory,  a 
situation  which  would  prevent  updating  of  the  file  branch 
data  by  the  secret  process  since  writing  "down"  is  not 
allowed.  This  restriction  is  not  felt  to  exclude  any 
significant  FSS  capabilities  and  provides  for  a  simplified 
implementation. 

The  modular  construction  of  the  FSS  enhances  System 
structure.  All  data  bases,  except  the  files  themselves,  are 
module  local.  Code  is  expected  to  be  written  in  PLZ/SI8 
[Snook] ,  which  is  a  high  level  pascal-like  structured 
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rogramminf  language.  Because  of  the  its  length,  code  is 
oca ted  in  Appendix  C.  The  code  listed  in  this  appendix 
rives  the  interprocess  and  intermodule  control  structure  of 
;he  FSS. 


1 .  Shared  Segment  Interactions 

Supervisor  process  execution  occurs  in  a  completely 
asynchronous  manner.  When  a  process  is  refered  to  in  the 
following  discussions,  the  two  Host  surrogate  processes  are 
being  referenced,  these  surrogate  processes  have  the  same 
clearance  levels  as  the  Best  they  represent. 

As  already  mentioned,  the  task  of  tne  ?SS  is  to 
provide  a  service.  To  he  of  maximum  benefit,  this  service 
should  he  unambiguous,  easy  to  use,  and  robust. 

The  major  problem  that  the  TSS  must  hanale  tor 
proper  System  security  is  the  confinement  problem,  viz.,  to 
prevent  a  process  from  reading  a  file  with  a  --i*?- 
classification  or  writing  (i.e.,  storing  or  updating)  a  fixe 
with  a  lower  classification.  This  job  is  handled  entirely  by 

the  Kernel. 

Another  problem  closely  related  to  the  confinement 
problem  which  also  in voles  the  Supervisor,  is  the 

"readers /writers"  problem  [Courtoisl .  In  order  to  preserve 
file  integrity,  reading  and  writing  of  s  shared  file  cannot 
be  allowed  at  the  same  time.  Since  a  primary  objective  of 
p55  <5  to  provide  for  the  sharing  of  files,  inis  problem 
will  certainly  occur  and  must  be  handled  properly  for  System 


viability. 

3oth  the  confinement  problem  and  the  readers/writers 
problem  can  be  solved  in  one  of  two  ways.  Mutual  exclusion, 
a  mechanism  which  forces  a  time  ordering  on  the  execution  of 
critical  regions,  forces  concurrent  processes  into  a  total 
order  execution  sequence.  Ibis  is  counterproductive  to  the 
purpose  of  a  process  structure,  which  inherently  allots 
concurrent  execution  of  processes. 

*  second  and  relativelx  new  Mtoofl  is  the  use  of 
eventcousts  and  seouencer  [Heed)  to  control  access  to 
critical  regions.  This  method  preserves  the  idea  of 
concurrent  processing  to  a  much  greater  extent.  An 
evestcount  is  a  object  that  keeps  count  of  the  number  of 
events  C in  the  case  of  the  TSS,  segment  read/write  accesses) 
that  have  secured  so  far  in  the  execution  of  the  System 
procedures.  These  eventcousts  are  associated  with  the 
Supervisor  segments.  They  are  accessed  only  via  Kernel  calls 
and  can  he  thought  of  as  non-decreasing  integer  values.  Each 
Supervisor  segment  has  two  eventcousts  associated  with  it, 
one  to  keep  track  of  the  read  accesses  and  one  to  keep  tr^ck 
of  the  write  accesses. 

A  Kernel  primitive  ABfABCl  signals  the  occurrence  of 
an  event  (read/write  segment  access)  associated  with  a 
particular  segment  evestcount.  The  value  of  an  eventcoust  is 
the  number  of  SBf.tHCE  operations  that  have  been  performed  on 
it.  A  process  can  observe  the  value  of  an  eventcottut  by 
either  BEA3!,Seg_*,  E).  which  returns  the  value  directly,  or 


by  IVAIT*:Seg_#,  ?,  t),  which  returns  when  the  eveotcoust 
reaches  the  specific  value  t. 

A  sequencer  is  also  necessary  to  solve  the 
confinement  and  readers/vriters  problems.  Some 
synchronization  problems  require  arbitration  Ce.g,,  two 
write  accesses  to  the  same  segment}?  eventcounts  alone  do 
not  have  the  ability  to  discriminate  between  two  events  that 
happen  in  an  uncontrolled  Ci.e.,  concurrent}  manner.  A 
seouencer,  like  event counts,  caa  be  thought  of  as  a 
non-decreasing  integer  variable  that  is  initially  zero.  Each 
Supervisor  segment  has  associated  with  it  one  seouencer.  fhe 
only  operation  on  a  sequencer  is  a  Eernsl  primitive 
operation  called  TICKlf (Seg_#«  5),  which,  when  applied  to  a 
sequencer,  returns  a  non-negative  integer  value.  (Similar  to 
getting  a  ticket  and  waiting  to  be  served  at  a  barber  shop.} 
Two  uses  of  TICIFT (Segja.S)  will  return  two  different  values 
corresponding  to  the  relative  ’time-  of  call. 

fha  segmert  number  associated  with  these 
synchronization  primitives  informs  the  Kernel  of  which 
5*»grp«*  being  referenced.  The  use  of  evertcousts  aad 
seouencer  can  he  illustrated  by  examining  the  following  two 
procedures  (read  O  as  net  equal),  fhe  F8S  implements  these 
functions  in  the  Direct or y_ Control  module  located  in  the  Ft? 


PROCEDURE  reader 
BEGIN  INTEGER  w? 

abort:  w  :=  READ* Seg_#  ,S  )  ?  !get  reader  eventcount! 

AWAIT(Seg_#, c7w)  *  !wait  until  write  complete! 
’’read  file” i 

if  READ  {See  #,S)  <>  w  THEN  GOTO  abort!  read  again! 
END 


PROCEDURE  writer 
BEGIN  INTEGER  t? 

ADVANCEfSeg  «,S)J  lincrement  reader  eventcount! 
t  TICKETTSeg_*,T);  !get  sequencer! 

AWAIT ( Seg__tf, C, tT ?  ! wa i t  for  write  to  complete! 
’read  and  update  file”? 

ADV »NCE(Seg_#, C ) i  lincrement  writer  eventcount! 

END 


The  Kernel  will  enforce  the  confinement  property  and 
prevent  the  application  of  the  ADVANCE  and  TICKET  primitives 
to  segments  with  an  access  class  less  than  the  Host  access 
class.  Not  to  do  so,  would  allow  a  communication  path  to  be 
created  between  two  different  access  levels.  The  two 
eventcounts  a  Supervisor  segment  will  have  associated  with 
it  (in  the  Kernel)  are  a  write  eventcount,  C,  and  a  read 
eventcount,  S.  Each  segment  will  also  have  a  seauencer,  T, 
associated  with  it.  Eventcounts  and  sequencer  are  initially 
zero. 

These  eventcounts  and  sequencers,  with.  their 
associated  Kernel  primitives,  are  used  by  the  ESS  to  perform 
the  synchronization  functions  of  Block  and  Wakeup  [Coleman] , 
described  in  the  original  Kernel  design.  Eventcounts  and 
seouencers  provide  a  clearer  picture  of  the  process 
interaction  as  well  as  explicit  control  of  the 
’readers /wri ters  '  problem.  Even  more  importantly,  they 
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permit  the  synchronization  between  processes  of  different 
access  levels.  This  is  essential  in  order  to  permit  a  high 
level  Host  to  read  files  of  a  lower  level. 

There  are  two  groups  of  Host  requests.  They  can  be 
classified  as  read  reauests  {e.g.,  P.EADJFILE,  BEAD_ACL)  and 
write  requests  (e.g.,  CREATE_FILE,  ST0RE_EIL3).  These 
categories  can  be  further  subdivided  into  read  data  file, 
read  directory  file  and  write  data  file,  write  directory 
file  subcategories.  Each  category  type  must  be  handled  in  a 
proper  manner  by  the  Supervisor  to  insure  file  integrity. 
Each  category  will  be  discussed  in  turn  beginning  with  the 
read  file  category. 

There  two  conditions  which  might  develop  over  which 
a  process  has  no  control?  file  update  by  another  process, 
and  file  deletion  by  another  process.  An  example  of  file 
update  might  occur  while  a  secret  process  is  traversing  a 
file  hierarchy  and  is  in  the  middle  of  searching  the 
directory  for  ar  Ertry_Name  when  another  process  (at  the 
directory  access  level}  updates  the  directory.  Since  the 
secret  process  will  READ  he  segment  "reader"  eventcount,  S, 
before  and  after  the  search,  it  will  know  that  the  data  it 
had  obtained  is  possibly  invalid.  Although  there  does  not 
appear  to  be  a  problem  with  allowing  the  ’reading’  process 
to  re-read  the  directory  file  until  a  "good"  read  is 
achieved,  a  closer  examination  of  this  condition  should  be 
made  at  implementation  time,  viz.,  is  it  possible  for  a 
'writing  '  process  to  alter  the  pathname  of  a  ’reading" 
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process  so  that  an  inconsistent  state  is  achieved  for  the 
reading  process?  A  possible  solution  could  reouire  a  process 
which  suffers  a  "bad"  read  to  begin  the  traversal  over, 
beginning  at  the  root  directory. 

When  a  directory  Is  being  read  to  pass  directory 
data  back  to  a  Rost,  the  directory  data  is  put  in  a  buffer 
and  sent  from  there. 

A  single  segment  buffer  nav  be  to  small  to  hold  a 
data  file  ( e.g maximum  file  size  of  256K  bytes). 
Therefore,  to  present  the  Host  with  only  valid  data,  a  data 
file  "buffer"  is  needed  at  the  process  level.  Since  this 
buffer  will  be  at  the  process  access  level,  it  can  be  locked 
by  the  process  to  insure  that  no  other  process  interfers 
during  the  reading  operation  once  the  data  file  is  in  the 
buffer  file.  This  copying  of  the  data  file  is  done  by  the  FM 
process  and  the  10  process  will  read  the  file  from  the 
buffer  file  when  transfering  the  file  to  a  Host  system.  The 
choice  of  making  a  copy  of  a  data  file  is  awkward  but 
considered  necessary  in  order  to  provide  the  Host  with  only 
atomic  operations,  ?.e.,  to  prevent  the  situation  from 
occuring  where  half  of  a  ten  segment  msf  is  transmitted  to 
the  Host  and  the  file  is  either  updated  or  deleted. 

The  other  condition  which  may  arise  during  a  file 
read  is  a  file  deletion.  This  situation  occurs  when  one 
process  is  reading  a  file  and  another  process  deletes  the 
same  file.  The  first  process,  not  knowing  that  the  file 
(segment)  has  been  deleted,  will  try  to  reference  the  file 
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again,  A  hardware  segment  fault  will  occur  and  cause  s 
transfer  of  control  to  the  Kernel.  Note  that  in  this 
situation,  it  is  the  higher  access  class  process  which  will 
suffer  the  fault  while  it  is  reading  a  lower  access  class 
file.  To  handle  this  problem,  viz.,  the  Supervisor  segment 
fault,  a  fault  handler  must  be  part  of  the  distributed 
Supervisor.  A  Kernel  primitive  also  needs  defining.  This 
primitive,  Ga tekeeper.On_Faul t  (Fault_condition,  Entry_pt), 
is  called  in  the  initialization  of  the  Supervisor  process 
where  it  is  possible  for  a  segment  fault  to  occur.  A  call  to 
a  Superivsor  condition  establisher  is  also  necessary.  This 
will  olace  a  specific  condition  handler  on  a  'condition 
stack"'.  If  a  fault  occurs,  the  Kernel  returns  to  the 
Supervisor  fault  handler  with  a  ’segment  fault'  error 
condition.  This  fault  handler  in  turn  transfers  control  to 
the  condition  handler  at  the  top  of  the  'condition  stack' 
which  can  make  a  normal  return  from  all  procedures.  When  the 
error  condition  is  detected  (from  the  return  code)  by  the 
appropriate  Supervisor  level,  action  is  taken,  viz.,  the 
Host  command  in  re-initiated.  Sint  the  file  (segment(s)) 
has  been  deleted,  this  reinvocation  may  well  result  in  a 
'segment  not  found'  error  condition  being  returned  from  the 
Kernel  and  a  "file  not  found"  error  condition  being  relayed 
to  the  Host.  When  the  Supervisor  exits  the  "segment  fault"  a 
"revert"  command  is  necessary  to  remove  the  condition 
handler  from  the  condition  stack. 

Another  side  benefit  of  having  the  Supervisor  do  all 


the  actual  file  reading  (and  therefore  take  all  the  segment 
faults)  is  that  it  prevents  a  hardware  fault  from  occuring 
during  the  actual  data  transfer  in  the  Kernel  during  T0 
process  execution*  this  condition  would  force  the  handling 
of  the  fault  in  the  Kernel  domain — a  difficult  task. 

Writing  a  file  is  a  more  straight  foreward  task  and 
presents  fewer  problems.  This  is  because  a  writing  process 
has  the  sane  access  class  as  the  file  ard  can  prevent  all 
other  access  to  the  file  ( segment ( s ) )  it  is  concerned  with. 
To  alter  a  directory  ( CBEA?E_FILE,  DELETE_FILE.  etc.),  a 
process  will  get  a  ticket  to  the  directory  and  perform  the 
necessary  manipulation  when  its  number  is  called.  In  order 
to  store  a  file,  more  care  must  be  taken.  If  a  process  were 
allowed  to  store  directly  into  the  old  file,  the  possibility 
exists  that  a  software  or  hardware  error  might  result  in  a 
partially  updated  file  and  loss  of  file  integrity.  To 
prevent  this  from  occurring,  a  data  file  is  first  stored 
into  a  temporary  file  set  up  by  the  EM  process.  This  also 
allows  the  original  file  to  continue  to  be  read  by  other 
processes  while  the  store  operation  is  going  on,  a 
significant  advantage  if  the  data  file  is  long,  After  the 
file  is  stored  by  the  10  process,  the  FM  process  gets  a 
ticket  to  the  file  directory  and  when  its  turn  comes,  makes 
the  necessary  directory  updates,  viz.,  the  temporary  file 
name  is  subsituted  for  the  old  file  Fntry_Name,  Ia$t_Update 
information  changed,  and  the  old  file  deleted.  (If  the  file 
is  a  msf.  each  segment  is,  of  course,  deleted.) 


2.  File  Management  Process 


The  ?M  process  is  composed  of  the  five  modules 
depicted  is  figure  S  (with  associated  Kernel  calls).  The  FH 
process  is  the  controller  of  the  FSS  and  directs  all 
interaction  between  the  FSS  and  a  Host  system.  Each  module 
which  makes  up  this  process  will  be  described  along  with  the 
procedures  which  make  up  the  individual  modules. 

a.  File  Management  Command  Handler  Module 

As  depicted  in  figure  3,  the  FM_C o mma n d_Ha n d 1 e r 
module  Ksee  Appendix  C,  ?,  104)  is  at  the  top  of  the  FM 
process  hierarchy.  This  is  the  level  of  abstraction  at  which 
Host  commands  are  "known".  This  module  is  responsible  for 
interprocess  communication  and  synchronization  (with  the  10 
process)  and  Host  command  interpretation.  Interprocess 
communication  is  achieved  by  the  Kernel  primitives  TICKET, 
ADVANCE  and  AWAIT  which  act  cn  an  eventceunt  associated  with 
the  shared  mail_box  segment.  Figure  9  shows  the  logical 
construction  and  *he  data  base  description  of  the  rail_box. 
figure  10  is  a  list  of  the  procedures  contained  within  the 
FH_Command_HaRdler  module  and  their  input  and  output 
parameters . 

The  FM_Cmd_Hnd  procedure  is  the  entry  procedure 
into  the  FM_Command_Eandler  module.  This  is  the  control 
procedure  of  the  module  and  is  responsible  for  routing  Host 
commands  to  specific  FM_Command_HandIer  procedures  for 
action.  When  notified  by  the  10  process  that  a  command 
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Procedure 

Input /Out put  parameters 

packet  is  in  the  n»ail_tox,  the  FM  process  retrieves  the 
command  and  begins  appropriate  action.  The  Host  command 
(e.g.,  STORE_FILE,  HEAt_FIlE)  is  actually  an  entry  into  a 
case  statement  which  directs  the  correct  FM_Command_Handler 
procedure  tc  take  action.  Each  Host  command  has  associated 
with  it,  at  this  level,  its  own  procedure. 

Because  the  procedures  of  the  module  are 
relatively  straight  forward,  they  will  net  he  discussed  m 
detail.  The  general  functions  of  all  the  procedures  in  this 
module  are  to  pass  instructions  ' o  the  10  process  aud  to  the 
Directory  Control  module,  the  "workhorse"  of  the  FH  process. 

Some  explanation  of  Host  command  parameters  is 
in  order,  however.  These  parameters  \ described  below)  are: 
pathname 
link 

file  type 
command  type 
file  size 
access  level 


userid 


entry. 


In  all  host  commands,  the  pathname  passed  by  the 
Host  is  the  pathname  (relative  to  the  ’root’  directory  of 
the  Host  virtual  file  system)  of  the  file  of  interest, 
whether  a  directory  or  data  file.  From  the  pathname,  the  FH 
process  is  able  to  extract  the  pathname  of  the  parent 
directory  which  It  must  brine  into  the  FH  "Process  memory  to 
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check  for  proper  discretionary  access.  The  complete 
pathname,  in  terms  of  the  FSS  file  system,  passed  to  the 
Birectory_Gontrol  module  for  actual  directory  manipulation. 
*  pathname  and  file  size  ( for  the  ' "buffer  file*)  is  returned 
(dir_pathname,  dir_file„si ze )  by  the  3irectory_Control 
module  during  a  Host  PFABJFILH  or  STQE3_?IL?  reauest.  This 
new  pathname  and  file  size  is  passed  to  the  TO  process  where 
the  actual  data  transfer  takes  place  for  these  operations. 
Since  discretionary  security  checks  are  made  in  the  FM 
process  and  all  input/output  "buffers"  (e.g.,  temporary  data 
file,  mail_bor  segment)  are  under  positive  FM  process 
control,  the  10  process  need  not  be  concerned  with 
discretionary  security  or  the  possibility  of  a  "segment 
fault  * . 

A  link  is  a  pathname  which  a  Host  passes  in  the 
C?.5ATE_LINX  command. 

File  type  is  used  for  the  CHEA?E_?II.I  Host- 
command  a  a  is  necessary  because  of  the  different  file 
formats. 

Command  type  is  used  in  the  HIAD^FILE  Host 
command  to  specify  the  type  of  "read’  the  FSS  is  to  conduct, 
i.e.f  to  read  a  directory  file,  a  data  file,  or  only  a  data 
file  size. 

File  size  is  passed  by  the  Host  during 
STOEE_FIl-l  requests.  This  information  is  necessary  for  the 
FM  process  to  create  a  temporary  file  of  sufficient  size  to 
jtore  a  Host  file.  File  size  is  relayed  to  the  10  process  so 
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that  the  10  process  can  go  directly  to  the  data  file  without 
having  to  check  the  directory  file  for  file  size.  File  size 
is  in  hits. 


Access  level  is  needed  for  the 


ssfi  FI LI 


command.  This  allows  for  upgraded  directories  (remember, 
data  files  cannot  he  upgraded). 

Ttp  identification  of  the  Host  system  user  is 
necessary  for  the  FSS  to  perform  discretionary  security 
checks.  This  is  provided  by  the  Host  system  through  the 
userid  parameter. 

ACL_s>try  is  used  with  the  ADD_ t CL_ENTEY  end 
D^IFTF  ACL  ENTRY  commands  to  give/rescind  discretionary 
access  to  files. 


b.  Directory  Control  Module 


The  Directory_Control  module,  as  the  name 
implies,  does  the  directory  manipulation  and  maintenance . 
Figure  11  lists  the  procedures  which  make  up  this  module 
along  with  their  input/ out put  parameters. 
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files  are  known.  The  Directory  Contorl  module  handles  the 
readers/ writers  problem  with  the  appropriate  use  of  the 
Kernel  syncronization  primitives  HEAD,  A Tv  ANTE,  skill,  and 
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segment  (which  contains  the  file  branch/link  entry)  must  be 
brought  into  process  memory  to  check  for  proper 


discretionary  access.  I?  access  is  permitted,  the 
Segment^ Handler  module  is  called  with  a  pathname  of  a 
segment  reauired  to  be  brought  into  process  memeory. 

ior  action  on  a  DE'LE7E_T  ILE  command, 
discretionary  write  access  to  the  directory  is  reouired 
since  the  branch /link  ent^y  of  the  file  must  be  removed  from 
the  directory  when  the  file  is  deleted.  (Note  that  this 
raises  the  possibility  cf  a  Host  having  write  access  to  a 
file  but  not  able  to  delete  it  because  he  does  not  have 
write  access  to  the  directory.)  I?  the  parent  directory  file 
is  not  found  or  found  but  write  access  to  the  directory  not 
permitted  an  appror"iate  error  code  is  returned,  viz.,  "file 
not  found"  or  "write  access  not  permitted". 

If  an  error  condition  does  not  arise,  the 
directory  is  broug.it  into  process  memory  and  a  check  of  the 
file  attributes  is  made  to  determine  file  type  (data, 
directory,  link).  If  it  is  a  data  file  or  link  entry,  it  can 
be  deleted  because  it  is  a  terminal  node  in  the  file 
hierarchy.  If  it  is  a  directory,  the  (directory)  file  itself 
must  be  brought  into  process  memory  to  see  if  the  directory 
is  empty  (viz.,  creek  of  Entry_Count  ard  presence  of  a 
Supervisor  temporary  file).  T?  it  is  not  empty,  an  error 
code  of  "not  terminal  file"  is  returned  to  the  Host.  If  the 
directory  is  empty,  it  can  be  deleted. 

If  no  error  condition  occurs  during  the 
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preceding  checks,  the  file  may  (subject  to  check  by  the 
Kernel)  be  deleted.  The  Dir_Cr.trl  .Directory  procedure  will 
call  on  Seg_Knd_Make JJnaadressable  procedure  which  will  in 
turn  call  Mem_Hnd_Swapcut  procedure  to  remove  the  segment 
from  process  memory  if  it  is  in  memory.  (Remember  the  actual 
order:  Swap.Ou*.  Terminate,  Delete.)  Next,  the  Kernel 
primitive,  OateKeeper .Delete.Segment  is  called  to  delete  the 
file  from  the  FSS.  Note  that  in  the  case  of  msf's,  these 
steps  must  be  repeated  until  all  segments  of  the  file  are 
deleted.  »t  this  time,  the  branch  entry  is  removed  from  the 
directory  by  zeroing  all  branch  entry  elements  (to  allow  for 
Kernel  secondary  storage  compaction  of  disc  pages  of  zeros). 
The  10  process  is  then  instructed  to  acknowledge  the  Rost 
with  "file  deleted".  This  frees  the  entry  for  future  use. 

The  deletion  of  a  link  requires  the  same 
discretionary  write  access  to  the  directory.  In  this  case, 
no  further  checks  are  necessary  and  the  link  entry  elements 
are  zeroed  in  t.hp  directory,  freeing  the  entry  for  re-use. 

Tor  the  nRFATF.m?  command,  analogous  action  is 
taken  by  the  Dir_Cnt.rl_Di rectory  procedure,  viz.,  to  check 
discretionary  write  access  to  the  directory  which  will 
contain  the  file  branch  entry. 

Once  this  check  has  been  satisfactorily 
completed,  and  room  pxists  in  the  directory,  the  Kernel  call 
Gatekeeper, Create.Segment  is  made  to  create  the  file.  The 
initial  file  size  is  zero  for  data  files  since  the 
Supervisor  has  no  prior  knowledge  of  the  size  of  the  file 


that  will  be  stored  in  the  branch  entry.  As  explained 
earlier,  a  file  size  of  LARGE  (SK  bytes)  was  selected  for 
the  fixed  directory  size. 

The  CEEATE_LIMX  reauest  is  again  analogous,  the 
only  difference  being  that  instead  of  a  branch  entry  being 
made  in  the  directory,  a  link  entry  is  made.  As  previously 
mentioned,  the  Supervisor  will  not  allow  a  loop  state. 
Checks  will  r><'t  be  made  at.  link  creation  time*  however,  the 
Supervisor  will  "abort'’  a  file  search  if  it  encounters  this 
error  condition  during  tree  traversal. 

The  R?1'D_FILT'  Mir)  command  reauires  read  access 
to  a  directory  file.  If  no  error  condition  arises  during 
discretionary  security  checks,  selected  directory  data 
(e.g.,  EntryJ'Jame,  ?ile_Size,  etc.)  is  transfered  to  the 
Host  system  via  the  mail_box  segment  (viz., 
Dir_Data_Buffer ) .  This  selected  directory  data  for  each 
"occupied"  branch/lirk  entry  is  transfered  during  the 
README ILE  1  dir)  command.  Eor  the  REAB_EILE  (size)  request, 
only  selected  directory  data  for  a  specific  data  file  is 
transfered.  The  10  and  FM  processes  use  appropriate  Kernel 
synchronization  primitives  to  assure  that  the  information  in 
the  mail_box  segment  is  valid. 

The  last  three  Host  requests  handled  by  the 
Bir_nntrl_Directory  procedure  are  related.  Again, 
appropriate  discretionary  access  checks  must  be  made  in  the 
parent  directory.  If  no  error  condition  arises,  the  action 
taken  is  straight  foreward.  In  the  case  of  the  EEAB_ACL 
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command,  the  file  ^CL  is  transfered  to  the  mail_box 
ACL_buffer  ard  the  proedure  returns  to  the 
Tv!_Command_tTandler  module.  In  the  case  of  the 
ADDCDUtrTI i_ACL_ZNTRY  commands,  the  action  is  completed  by 
the-  Dir_Ontrl_Directory  procedure  and  the  appropriate 
Dir_Succ__CodP  returned. 

The  Dir_CRtrl_Bata  procedure  is  responsible  for 
transfering  to/fr'un  a  Host  a  requested  data  file  if 
necessary  orecondlt iors  are  met  (viz.,  discretionary  and 
non -discret  1  onary  security).  Ir.  order  to  read  or  store  a 
file,  a  Host  must  have  the  proper  discretionary  access  to 
the  file.  To  check  this,  the  parent  directory  which  contains 
the  file  branch  entry  must  be  brought  into  memory.  This  is 
done  by  the  Segment_Eandler  module.  If  the  proper  access  is 
rot  allowed,  an  error  code  is  returned  to  the 
?M>_Command_Handler  module  for  relay  to  the  Host  system.  If 
the  proper  access  is  allowed,  a  copy  of  the  file  is  made  in 
the  case  cf  the  RE.4D_FILE  command,  or  a  temporary  file  is 
created  in  the  case  of  the  STORE_EILE  command.  The  pathname 
and  file  size  cf  the  data  files  to  be  transfered  are  passed 
to  the  10  process  which  will  perform  the  actual  data 
transfer.  Upon  a  successful  transmission  cf  the  data  by  the 
TO  process,  the  process  instructs  the  10  process  to 
acknowledge  the  Host  with  a  "read  complete"  or  "store 
complete  ’,  as  appropriate. 

The  Dir_Cntrl_Data  procedure  will  make 
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.  ,  „alled  to  update  the  directory  data  i'1*” 

prCCe  Ur"  ‘  nle  entry  Same  with  the  old  file 

exchange  the  temporary  file  -n  j_ 

me  f The  temporary  file 
»  i^pietes  the  old  file. 

Entry  Name)  3  -  ■'  ■  J  +  +  0-n  ntin*  to 

should  he  deleted  hy  this  procedure  if.  »P»  •«"'*  ' 

slire  each  director,  segment  has  only 

-at_  come  delay  may  °e 

artf  file  for  file  update. 

temporary  me  large 

if  cowcral  try  to 

.  w  unnt  systems  n  - e 

experienced  “  .  up  a 

,  ines  not  appear 

mes  into  the  sane  directory.  -1-  - 

us=rs  are  anticipated  to  - 
najor  prohlem  since  most  us..s 

,  .voir  rwn  directory  files, 
operating  from  their 

Tke  n-  Cntrl  Update  procedure  is  als* 

th.  case  of  a  Bost  abort 

free  the  temporary  storage  . 
command . 


c.  Discretionary  Security  Module 
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retionary 
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r.  Appro 
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use  of 
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condi  tior. 

be 

made  befo 

re  any 

attempt  t 

o  read 

d  n  ACL 

■  re* 

urn  is  ex 

e  cu  t  ed 

to  the  Qi 

rector 

y_ Control 

eve 

at  o?  a  f 

ault.  T 

here  sre 

four  d 

rocedures 

which  make  up  this  nodule  as  depicted  in  figure  12, 

The  Disc_Sec_Check_access  procedure,  as  the  name 
implies,  checks  f^r  a  specific  user  discretionary  access  to 
a  specific  file,  e  success  code  returns,  indicating  the 
result  of  the  check.  This  discretionary  ch^ck  is  only  made 
on  the  specific  file  which  is  reouirec  in  a  Host  command. 


i.e, ,  a 

design 

choice 

was  made  not 

to 

make 

discretionary 

access 

checks 

during  the  t-ee 

trave 

rsal 

search  for  the 

specif! 

ed  file 

.  This 

makes  explici 

t  in 

one 

ACL  who  has 

access 

to  a 

file. 

which  cor,  tri 

butes 

to 

clear  security 

semantics.  (This  also  eliminated  the  Question  of  what  to  do 
if  an  intermediate  directory  was  encountered  during  a  file 
search  to  which  the  process  did  not  have  read  access.) 

The  Bisc_Sec_®dd_rCL_Entry  procedure  adds  an 
ACL_entry  to  a  file  ACL  and  returns  a  success  code  to 
indicate  the  action  taken.  »s  noted  previously,  a  directory 
has  a  limited  number  of  ACL_entry  elements.  The  Supervisor 
only  guarantees  ore  ACL_entry  element  per  branch  entry  (for 
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PROCEDURE 

Bisc_Sec_ 
Check  Access 


BiscSec 
idd  A CL “Entry 


Di sc_Sec 
Get~Entry 


INPUT 

ACL 

AGL_Entry 

Userid 


ACL 

ACL  Entry 
Userid 


Disc_Sec_  ACL 

Delete  ACL  Entry  ACL  Entry 

Userid 


ACL  JEn try 
Userid 


OUTPUT 

Disc  Succ  code 


)isc  Succ  Code 


Disc  Succ  Code 


Disc  Succ  Code 


Pi sure  IP.  Discretionary  Security  Module 
Procedure  In out /Cut put  Parameters 


The  last  procedure  of  this  nodule  is  the 
Disc_Sec_Get_£ Cl  procedure.  It  is  used  during  the  intiel 
creation  of  a  file  "by  the  direct or;/_rentrol  module  to  get  an 
initial  ACL_Ertry  element. 

d.  Segment  Beadier  Module 

The  Seemer.t_Eandler  module  is  the  abstraction 
level  at  which  Supervisor  segments  are  known.  This  module 
works  in  conjunction  with  the  KemG’-y_Bandler  module 
'described  later)  to  either  brine  a  segment  into  process 
memory  (vi?,,  Ha,-e_E',own,  Swau_Ir )  or  to  terminate  a  segment 
(viz.,  Sva?_0ut,  Terminate^.  This  module  is  responsible  for 
maintaining  the  7M_KST  •'>" own  segment  table — figure  13)  data 
base.  The  data  base  elements  of  the  ?H_XST  are  the  pathname 
of  a  segment  known  to  the  process,  the  segment  number 
(Seg_#)  of  the  terminal  file  in  this  pathname,  -rode  (i.e., 
read  or  writei,  and  the  us?  bit.  necessary  for  a  LEU  re-oval 
algorithm  (approximation).  To  prevent  the  situation  where  a 
segment  has  been  deleted  by  one  process  but  is  still 
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Pathname 


See  * 


Mode 


Use 


Figure  13.  FM  K5T 
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Seg_Pnd_  Pathname 

Make  Addressable 


Seg_Hnd_  Pathname 

Make  Unadd ressahle 


OUTPUT 


Seg 

Seg. 


Slice  Cede 


Seg  Succ  Cods 


Figure  14.  Segment_Handler  Module 
Procedure  In  put /Output  Parameters 


indicated  as  "in  «er«Tr"  *y  another  process,  each  new  nos 
command  will  initiate  a  kernel  ceil,  Gateheeper.Svao.I 
(See  a.  Base  IUr),  to  confirm  the  existence  of  a  segment, 
hernel  return  of  "segment  not  found"  .ill  indicate  that  th 

segment  has  been  deleted.  The  ^SS  must  then  clear  its  da! 

. ,  a  _  *  -  j  *  r-g  it  sot'c.p  the  virtue 

./*  ill  1  did  C  !*i  •#A°*W* 

$t  njctures  o  in^ss  j 

hierarchy  from  the  root  directory  to  insure  that  the  seesneR 

,  i  -  c  nejd-  >-»s=r  renamed  by  anotn* 

is  truely  gone  and  that  it  has  n,,  ce.a  - 

♦■vo  situation  where  a 

*  ,=  4  a  ridvpr  tn8  u?.i 

pathname  has  been  deleted  and  then  re-created  with  the  name 
filenames-  This  would  associate  dixf..ent  s_f.. 

vi th  the  same  pathname. 

«.  net  of  the  proedures  of  this 
?i gu  rp  14  is  «  ns*  w*  * 

module  along  with  their  inout/output  parameters.  This  module 

receives  a  file  segment  pathname  and  returns  when  it  has 

4t  «  _  -s  »=  Dt'  condition 

been  brought  into  process  Memory  or  =- 

. . ,  ,fini?5t4ns  that  might  re  returned 

arises.  The  possible  error  condition 

i'nuci  *  This  module  has  two 
from  this  module  is  r0"  !°jU  1  - 

. _  .  To  ma’se  a  segR“itt 


-  i  -  __  /» i  ■»  *  rnuDi  .  5-; w ^  — — -  — 

from  this  module  is  i1--  r0w 

ta s*cs ,  ard  the^efere  two  procedures.  To  mase  a  segR^.t 
a.j  a  passable  by  the  rost  process  tviz.,  brine  it  int0  p*oceSS 
memory)  or  to  mahe  a  segment  unaMressahle  hy  a  Host  process 
.  to  remove  the  segment  from  process  memory).  The 


to  pro 


memory • 
segment  from 


a  segmen 


known'  and  that  making  a  segment  unaidressable  requires 
"terminating"  the  segment.)  Both  tasks  are  accomplished  by 
appropriate  use  of  Kernel  primitives  and  accompanied  by 
calls  to  the  ftemory  Handler  module  to  Swan  In  or  Swan  Out  a 


segment. 


This  module  is  also  responsible  for  segment 


management.  Segment  management  is  necessary  because  each  MMU 
allows  the  addressing  of  only  64  semen ts .  With  one  MHU  in 
the  initial  ?SS  implementation  and  several  segments  taken  by 
the  Supervisor  and  Kernel  segments*  the  number  available  to 
the  Supervisor  nrocesses  will  he  somewhat  less 
KNOWN  SKO )  than  64.  This  nunber  must  be  managed  in  a 
dynamic  manlier  without  interfering  with  process  execution. 

The  Seg_Knd^Kake_Addressable  procedure  is  the 
more  involved  of  the  two  module  procedures.  If  a  recuest  to 
make  a  segment,  known  is  received,  the  is  checked  to 

see  if  it  is  already  known.  If  it  is,  the  1RD  bit  is  set  end 


the  KemcryHard ler  module  is  called  to  assure  that  the 
segment  is  in  process  memory.  If  it  is  not  already  known  to 
the  process,  it.  mist  be  made  known  by  the  Kernel  call, 
Gatekeeper .Hake_Known  (Par_seg_s,  entry_#,  node).  But  this 
can  only  be  done  if  process  segment  limit  is  rot  exceeded. 
If  the  addition  of  a  segment  will  cause  an  overflow,  a 


nt.  must  be  removed  by  the  See  and  Fade  unaddressable 


procedure.  Once  this  is  done,  the  desired’  segment 


can  oe 


made  known,  the  TF  KST  updated,  and  the  Fernery  aandler 
module  called  to  bring  it  into  process  memory. 


The  See  Hnd  Make_0naddre3sahle  procedure  is 
straight  foreward.  This  procedure  may  be  called  to  either 
delete  a  specific  segment  or  to  delete  the  ISO  segment.  If 
called  to  remove  a  specific  segment,  action  is  taken  to 
remove  the  segment  (described  below}.  If  called  to  remove 
the  LBU  segment,  a  lPu  removal  algorithm  f approximation)  Is 
used  to  determine  which  segment  will  be  removed.  When  this 
has  been  done,  the  Memory_?andler  module  is  called  to 
Swap  Cut  the  segment  from  process  meir-nry.  A  returned  success 
code  indicates  that  the  segment  has  been  removed  by  the 


_  •*  *  n  . 

Cil  1x0 

tekepper.SwapCut 

--  “  j 

\  w  t  *  /  • 

A  ca 

mirate 

the  selected 

segment , 

The 

Gatekeeper. Terminate  (?ar_Seg_-,  ?ritry_K«>,  will  cause  the 
segment  to  be  deleted  from  the  Kernel  E3T.  Removing  the 
segment  pathname  from  the  ?“_KST  will  complete  the  action 
taken  by  this  procedure. 

0*  r  HcTjuIpT'  ul  0 


This  nodule  operates  in  « 
Segment ^Handler  nodule  and  consist  of  ti 
procedures  are  listed  in  figure  1! 


slave  mode  to  the 
procedures.  These 
along  with  their 


in put /output  parameters.  The  job  of  this  module  is  to 
dynamically  manage  a  fixed  site  linear  virtual  memory.  It 
does  this  by  swapping  in  and  out  of  process  memory  segments 
as  reouired. 

'iVipf  the  Kem  Hnd  Swap  In  Procedure  is  called, 
the  ??-*  r 5? ,  figure  I15,  (active  sesnent  table)  is  checked  to 


.  M 


may  be  reauired  in  process  memory  during  the  copying  of  a 
data  file  into  the  data  file  "buffer”.  A  24K  byte  memory 
would  allow  for  the  worst  case,  viz.,  one  SS  byte  segment 
positioned  in  the  middle  of  linear  memory;  room  would  still 
exist  for  the  two  3K  byte  segments. 

3.  Input/Output  Process 

The  10  process  is  the  second  of  the  two  processes 
which  act  on  behalf  of  a  Host  system  to  provide  a  requested 
file  management  service.  The  10  process  acts  in  a  slave  mode 
to  the  FM  process?  it  receives  its  commands  from  the  FM 
process  via  the  shared  mail_box  segment  described  in 
connection  with  the  FM  process. 

The  10  process  is  responsible,  as  the  name  implies, 
for  all  input  and  output  between  the  Supervisor  and  the  Host 
systems.  The  10  process  is  composed  of  five  modules  as 
depicted  in  figure  18  (along  with  Ker'el  calls).  Two  of 
these  modules,  Segment_Handler  and  Memory_Handler ,  are  the 
sane  modules  as  described  in  th°  FM  process  and  will  not  be 
discussed  further.  Their  task  is  to  bring  into  the  virtual 
memory  of  the  10  process  the  data  segments  into  and  from 
which  Host  files  are  stored  or  read.  Note  that  since 
discretionary  security  checks  are  done  ir.  the  FM  process, 
the  10  process  does  not  have  to  repeat  these  checks. 

Direct  invocation  of  the  ?acket_Handler  module  from 
the  IO_ComrrK.  d_Handler  module  is  possible  to  send  Host 
"acknowledgements".  If  a  file  is  to  be  read  or  stored,  the 
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Figure  1R.  10  Process  Module 
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File  Handler  module  is  first  called  to  perform  the  read  or 


store  operation. 


The  10  process  is  also  responsible  for  FSS-Hcst 


protocol.  Data  is  transfered  between  Host  and  FSS  via  fixed 


size  'packets".  There  are  three  formats  for  these  packets: 


1)  a  synchronization  packet  format,  2)  a  command  packet 


format  and,  ?'*  a  data  packet  format.  Figure  19  gives  the 


logical  construction  of  the  data  and  commend  packets.  The 


synchror ization  packe*  is  left  for  later  design  in 


connection  with  the  design  for  a  Host  interface.  The  packet 


size  of  521  bytes  for  data  and  command  packets  was  chosen  to 


maximize  data  transfer  efficiency  at  the  expense  of 


increasing  the  command  packet  size.  Because  512  bytes  is  the 


si2e  of  the  smallest  Supervisor  segment,  this  was  chosen  as 


the  'unit'  of  data  transfer. 


a  protocol  must  exist  that  insures  reliable 


transmission  and  reception  n?  packets  by  both  the  sender  and 


receiver  in  the  FSS-Host  packet  exchange.  The  simplest 


protocol  that  will  handle  packet  transmission  is  to  transmit 


packets  one  at  a  time  and  wait  for  packet  acknowledgement 


before  sending  the  next  packet.  The  following  diagram 


illustrates  this  simple  protocol. 
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Figure  19.  Packet  Construction 


Operating  in  this  fashion  is  extremely  inefficient, 
especially  in  the  transmission  of  large  data  files*  it  does 
not,  allow  the  sender  to  send  cachets  before  an 
acknowledgement  is  received  nor  does  it  allow  the  receiver 
to  accept  more  that  one  packet  at  a  time  (i.e.,  read  ahead 
and  write  behind).  A  multi-packet  protocol  is  necessary  to 
take  advantage  of  a  read  ahead  and  write  behind  scheme. 

In  specif ing  a  multi-packet  protocol,  some  means  of 
distinguishing  individual  packets  rust  be  established.  This 
is  done  by  giving  each  packet  a  seouence  number  carried  in 
the  packet  .eader.  The  receiver  returns  acknowledgements 
indicating  the  seouence  number  of  the  packet's)  received  and 


accepted 

1  i  .e 

. ,  no  errors 

detected) . 

The  number  of  packets 

that  may 

be 

transmitted 

before  an 

acknowledgement  is 

received 

is 

called  the 

packet  "wi 

ndov  width".  Packet 

transmission  is  controlled  by  an  algorithm  which  uses  packet 
seouence  numbers  ana  the  window  width.  At  System 
initialization  time  and  anytime  a  command  packet  is 
received,  the  seouence  number  of  the  FSS  is  reset  to  zero. 
Thus  the  first  seouence  number  expected  by  the  ?SS  upon 
system  initiation  (and  afterwards  upon  command  completion) 
is  zero. 


"or  an  explanation  of  how  the  packet  window  works. 


let  N ( t ) 

denote 

the 

tra*» 

s^-i  t  ted 

seouence 

number 

of  th  e 

current 

packet 

and 

let 

N(t+1 ) 
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he  next 

expected 

seouence 

’"jmber . 
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wj  nd  o 

w  width 

is  denoted 

t-y  W. 

At  the 

start  of  communication,  e.g.,  when  a  Host  sends  a  command  to 
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the  FSS ,  the  Host  is  allowed  to  transmit-  packets  hearing 
seausnce  numbers  in  the  range  (KN^t  KW.  The  receiver  expects 
the  packets  to  arrive  ir  correct  sequential  order.  As  they 
arrive,  packets  are  checked  for  correctness  ;'at  both  the 
hardware  (USAHT)  and  software  level)?  an  incorrect  packet  is 
discarded  and  may  be  considered  ’lost*,  let  the  seouence 
number  of  a  particular  correctly  received  packet  be  S.  If 
S=N  f  t-l )  (i.e.,  the  expected  packet),  then  the  packet  is 
received  in  the  correct  soouence  and  it  should  be  accepted 
by  the  receiver  and  ap  acknowledgement  sent  with  the  proper 
seouence  number  (in  this  case,  S)  to  the  sender.  If 
Sk'f'Ht-l),  then  the  packet  is  a  repetition  of  a  packet 
previously  received  by  the  receiver?  the  second  transmission 
may  be  due  tc  either  a  lest  or  delayed  acknowledgement.  The 
receiver  should  generate  another  acknowledgement  end  send  it 
to  the  sender  ard  otherwise  ignore  the  packet.  If  3>N(t+l), 
then  the  packet  is  ahead  of  seouence,  indicating  that  an 
earilv  pac-'.  '.as  bee’1  lost?  such  a  packet  should  be  ignored 
and  an  "error"  acknowledgement  sent  so  the  packet  can  be 


retransmitted. 


fhe 
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cknovle 

dgeme 
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acknowledged,  packet  ¥  can  be  sent, 
lost  in  transmission  as  well  as 


Acknowledgements  can  get 

received 


ae 


packets.  If 
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acknowledgement  does  not  refer  to  the  earliest  transmitted 
packet,  awaiting  acknowledgement ,  theo,  in  this  protocol,  the 
seeder  may  safely  delete  all  packets  up  to  and  including 
that  refererced  hy  the  acknowledgement .  Against  each  copy  of 
a  transmitted  packet  will  he  noted  a  time  (i.e.,  the 
time-out)  hy  which  time  the  packet  rust  he  acknowledged. 
Failing  such  an  acknowledgement,  the  packet  must  be 
retransmitted  with  its  original  seouence  number.  A  packet 
will  only  he  received  in  sequential  order,  so  it  will  be 
necessary  to  re^ra^s^it  r.ot  only  the  earliest  unacknowledged 
packet,  hut  also  all  later  packets.  The  following  figure 
illustrates  this  protocol.  The  Queues  should  be  considered 
as  circular  with  automatic  wrap-around. 


f 
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Packet  5  — > 


< —  Ack  3,4 


In  this  figure,  the  sender  is  node  a  and  the 
receiver  is  node  B.  Node  A  has  sent  out  packets  3,4,  and  5, 
the  last  of  which  is  still  in  transit  to  B.  Node  B  has 
received  all  packets  up  to  and  including  4.  It  has  just 
acknowledged  3  and  4  and  Is  ready  to  accept  5,6,  and  7  when 
they  arrive  in  order.  When  node  A  receives  acknowledgement 
for  3  and  4,  it  will  be  able  to  transmit  successfully 
6  and  ?. 

This  protocol  irsures  that  packets  are  handled  in 


rackets 


sequential  order  which  will  insure  that  the  data  is  received 
and  stored  correctly.  It  also  assures  positive  control  over 
the  receipt  and  transmission  of  packets?  a  necessary 
reauirement  to  prevent  "buffer  overflow  and  loss  cf  data. 

The  Kernel  controls  all  the  hardware  assets,  as 
explained  in  Chapter  1.  Kernel  calls  are  therefore  necessary 
to  transfer  packets  between  the  FSS  end  the  Host  systems. 
The  format  of  these  Kernel  calls  are: 


Gatekeeper .Setup  (Buff_Addr,  Mode,  Status) 
Gatekeeper .Send_?acket  'Offset,  Status) 

Gatekeeper. Store_?ccket  (Offset,  Status) 

Gatekeeper. Change  Byte  Counter  of  Bytes,  Status) 


Each  hardware  port,  is  virtualized  into  ar  input  end 
an  output  port.  Each  virtual  port  has  associated  with  it  a 
unit  control  block  (UCB)  at  the  Kernel  level.  The  elements 
of  these  UCB's  are: 

Byte^Counter :  This  element  is  used  to  keep  track  of 
the  number  of  bytes  that  have  been  transmitted  or  received. 
This  counter  is  modulo  "packet  size"  so  that  ^ce  packets 


are  synchronized,  they  should  remain  so.  It  can  be  altered 
by  the  Change_Byte_Counter  call  in  order  to  get  the  FSS  and 
aost  back  into  packet  synchronization. 

3uf f er_Add ress :  This  is  the  starting  address  in  the 
input/out  buffer  whe^-e  packets  will  be  placed  Cinromrains)  or 
taken  from  (outgoing).  It  is  initialised  by  the  Setup  Kernel 


. . . 


Tuf fer_Lengthi  This  element  is  the  length  (in 
packets)  of  the  input/output  Puffer.  This  allows  the  Kernel 
to  perform  automatic  wrap  around  at  the  end  of  the  Puffer. 

Wirdov_¥idth:  This  element  is  used  by  the  input  port 
UCB  to  present  Puffer  over  flow.  Each  invocation  of 
5tore_?acket  will  advance  the  window  and  allow  another 
packet  to  Pe  stored  into  the  10  Puffer.  If  a  Host  system 
violates  protocol  Py  sending  too  many  p-acke*s,  the  Kernel 
will  dump  them  to  a  "bit  Packet",  fhis  »*iemem  is  used  by 
the  output  port  to  control  the  number  of  packets  that  the 
TSS  is  aPle  to  send  to  a  Host  before  receiving  an 
acknowledgement,  sithoueh  this  parameter  (viz..  window- 
width)  may  be  different  for  the  various  Host  systems,  it 
should  not  change  often  and  can  therefore  Pe  set  at  system 
initialization . 

Fo^  a  store  operation  (FSS  to  receive  packets),  a 
Setup  call  is  used  to  set  the  input  UCB  base  address  to  the 
initial  storage  location  in  the  10  buffer.  A  Setup  call  is 
also  rea uired  to  set  the  output  UCB  with  the  base  address  in 
the  10  buffer  from  which  acknowledgments  will  be  sent.  It 
should  Pe  noted  here  that  the  10  buffer  in  the  IC  process  is 
the  location  that  packets  are  checked  for  errors  and 
"enpacketed"  or  "depaeketed".  It  is  just  a  intercalate  stop 
for  data  and  neither  the  final  destination  no'!*  origin  of 
da  ta . 

Subseouert  Kernel  calls  to  Store_?acket  will  return 
the  location  of  the  next  packet  in  the  10  buffer  to  be 


the  10  buffer 


processed.  The  Kernel  will  store  ahead  into 
during  the  store  operation  but  will  not  over  write  the 
buffer.  That  is,  each  call  to  the  Kernel  will  indicate  th  .x 
a  new  packet  location  is  open.  The  10  process  will  control 
which  packets  ''and  h*v  many)  are  sent  to  the  FSS  by  proper 
use  of  acknovledeemen ts  'for  both  correct  and  incorrect 
packets) . 

Two  Setup  calls  are  also  necessary  for  a  send 
operation.  They  again  set  the  virtual  input/output  ports  for 
the  transfer  of  cachets  from  the  ?SS  to  a  Host.  Subseouent 
calls  to  Send_Packet  indicate  that  a  Packet  is  ready  to  be 
transmitted.  The  10  process  knows  when  it  can  discard  a 
packet  by  the  acknowledgments  it  receives  from  the  Host 
system. 

The  *'hanffe_‘Byte_Counter  primitive  is  used  by  the 
synchronization  procedure  to  shift  a  UCB  byte  counter  in. 
order  to  brine  packet  transmission  back  into 
synchronization.  (Synchronization  may  be  reauired  during  a 
temporary  communication  interruption  or  system  start  up.) 

The  following  is  a  description  of  the  three  ’’new’ 
modules  which  make  up  the  10  process. 

a.  I ’’put /Out  put  Commend  Handler  Module 

*t  the  top  of  the  TO  process  module  hierarchy  is 
the  I0_Comr a’-d_Far,,ler  module  ^see  Append ir  G,  p.  11?).  This 
module  is  responsible  for  the  interface  with  the  PM  process. 
Communication  between  the  processes  is  via  the  mail_bot 


snared  segment  and  synchronization  is  through  the  use  of  an 
eventcount  and  the  Kernel  primitives  TICKET,  ADVANCE  and 
AWAIT.  The  procedures  of  this  module  along  with  their 
input /output  parameters  are  listed  in  figure  22. 

The  1 0_r‘nd_Rnd  procedure,  like  the  7M  Cmd  End 
procedure  a  case  statement,  routes  process  instructions 
to  a  specific  IO_?'cmmand_"andler  procedure  for  action. 

The  procedure  involved  when  the  Host  command  is 
not  a  R^AHJFIL*  or  STOR”!!?  reauest  is  the  IC_Cmd_Hnd_AcR 
procedure.  This  procedure  is  able  to  invoke  the 
Packet  Handler  module  directly  for  performing  directed  { by 
the  ?iy  process )  Host  acknowledgement  ard/or  data  transfer 
from  the  shared  cnail_fcox  segment. 

The  I0_C"v3_Hrd_Send  and  IC_Cmd_Hnd_Store 
procedures  are  relatively  straight  forward.  They  provide  the 
IC-FM  process  interface  reouired  for  a  HSAD_FII.f  or 
3T0E?_TILE  "ost  reouest.  loth  procedures  call  the 
File_Hardler  module  to  perform  the  actual  file  meni pulaticn . 

b.  Pile  handler  Module 

The  File_Eandler  module  is  required  for  file 
manipula tion  in  the  TO  process  and  is  the  level  in  the  10 
process  at  which  files  are  krovr.  The  Procedures  which  make 
up  this  module  along  with  their  in  out/out  put  parameters  are 
listed  in  flgurs  21.  ?s  mentioned  above,  there  are  only  two 
Host  reo vests  that  reouire  the  10  process  to  bring  data 
files  into  process  memory.  These  are  READ  FILS  and 
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10  Cmd  Hnd  Mail  Box. Msg. Inst 


OUTPUT 


Cutout  returned 


IO_Cmd 

-vAJ.cz 

IC_CH_ 

Bna^Send 

IC_Cr.d_ 

C  t  n?*S 


Mail_Box.Msg.Succ_Ccde  from  subordinate 

modules. 

Meil_3cx  .Msg .  Pathname 
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Figure  2?.  IG_ Command _Ear.d ler  Module 
Procedure  Incut  /Output  "parameters 
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OUTPUT 


File_Hnd_  Mail_3ox  .Msg.  Pathname  Pile_Suce_Code 

Ser.d_?ile  Mail^Bor.iMsg.PileSize 


’ile_Fnd_  Mailbox. Msg. Pathname 
Store  Pile  Mail  Box .Msg. File  Size 


Pile  Succ  Code 


Figure  21.  ?ile_Randler  Module 
Procedure  Input /Output  Parameters 
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STOSi  FIX'?.  Note  that  since  file  s  1 2 2  is  passed  from  the  PM 
process,  and  the  the  access  to  the  data  files  involved  is 
controlled  in  the  PM  process,  data  file  segments  can  he 
brought  directly  into  10  process  memory  and  any  requirement 


for 

the 

TO  process 

t  f\ 

V  W 

access  directory 

files  (other  than 

tree 

trav 

ersel }  is  elim 

in 

ated.  Because  the 

terminal  codes  in 

f'Ho 

t^ee 

traversal  are 

CO 

ntrolled  by  the 

vv,  "Drocsss,  the 

nathn  to  these  terminal  —odes  will  not  he  alterable  until 

control  is  released  hy  the  PM  process. 

The  Pile  Handler  module  consist  of  two 

procedures.  Pile  Hnd_Send_Pile  (for  Host  command  nF.«B_FIl-E) 
and  Pile  End  Store  Pile  f f or  Host  command  ST0S1_FIXE).  Both 
procedures  operate  is  a  similar  manner,  Boos  receiving  a 
pathname  and  file  site  from  the  ?M  process,  these  procedures 
use  the  Segment  Randier  procedures  to  bring  the  necessary 
data  file  *  segment (s))  into  process  memory.  S  call  is  then 
made  to  the  ?acket_Handler  module  to  transfer  data  from/to 
specified  segments. 

The  order  of  events  in  the  reading  and  storing 
of  data  files  follows  the  following  sequences.  For  a 
EP»X*  FIX-  operation,  the  order  of  actions  taken  by  the 
Supervisor  are: 

1)  "niscreti onary  and  non— discretionary  checks 

are  made  in  the  PM  process. 

2)  s  copy  is  made  of  the  data  file  into  a 

per-process  data  file  buffer. 

y }  The  pathname  of  the  data  file  to  be  read 
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is 


(remember,  -directory  late  is  read  by  the  PH  process)  is 
passed  to  the  10  process  along  with  the  file  size,  fhe  10 
w!* 0 ces c*  ^ too  th^  f|lg  tgp  dl^SCtOFT 

but  by  pass  ice  file  size  to  the  10  process,  this  step  is 
eliminated  for  the  10  process. 

4)  The  read  takes  dace  is  the  10  process. 

51  The  10  oroce^c  .st tn  the  tH  o^ocess  with 


success  code 


re« 


i4  r* 


oaplete"  or  an  appropriate  error 


code.  The  s**!?  reasor  for  a  read  operation  to  fail  in  the  10 
process  is  the  receipt  of  an  abort  coBpand  from  the  Host  or 
a  ’time  oct^  which  would  occn*  1?  the  Host  stouusd  sscfliBs 
for  some  unexplained  reason. 

6)  fhe  PM  process  instructs  the  10  process  to 
acknowledge  the  “read  complete"*  or  tc  send  the  appropriate 
error  code,  fhe  data  file  read  buffer  is  then  free  for 
farther  use. 


I?  th“  operation  is  a  SIDES  FILS  operation  the 
following  steps  are  taken  by  the  Supervisor: 

1)  Discretionary  and  nor-— discretionary  security 
checES  are  cade  by  the  PM  process. 

2)  I  temporary  file  is  created  by  the  Supervisor 
large  enough  to  store  the  file  in.  *ppropriate  use  of  the 
synchronization  primitives  urevents  this  temporary  file  from 
being  used  by  more  than  one  Process  at  a  time. 

3)  The  pathname  of  the  temporary  file  is  sent  to 
the  10  process  and  the  10  process  stores  the  file  into  the 
temporary  file. 


4)  The  10  process  returns  a  success  code  to  the 
?M  process  and  the  FM  process  updates  the  directory  to 
reflect  the  new  file  (viz.,  Entry_Name  of  temporary  file  is 
changed  to  the  old  file  Fntry^Name)  .  The  old  file  is  then 
deleted  hy  the  FM  process. 

5)  The  FM  process  then  instructs  the  10  process 
to  acknowledge  the  "store  complete".  There  is  no  reason  a 
store  operation  should  fail  other  than  an  explicit  abort 
reauest  by  the  Host  system  or  hardware  failure. 

c.  Packet  Handler  Module 

The  Packet  Handler  module  does  the  actual 
transfer  of  data  between  the  FSS  and  the  Host  system  and  is 
the  10  process  level  at  which  the  ccncept  of  "packet  is 
known.  The  procedures  of  this  module  along  with  their 
input  /output,  parameters  are  listed  in  figure  22.  The  tasks 
that  this  module  must  perform  are:  1)  synchronization  of 
packets,  2)  error  detection,  3)  packet  acknowledgement,  and 
4)  transfer  of  data  to/from  Supervisor  segments.  Figure  23 
is  a  finite  state  diagram  of  packet  transfer. 

The  synchronization  task  is  performed  on  the 
system  IPL  and  whenever  packet  synchronization  is  lost 
thereafter.  Frror  detection  and  reauest  for  retransmission 
upon  error  detection  are  compl iment cry  functions  which  are 
performed  on  every  packet  received  from  a  Host. 

Packet  transfer  during  synchronization 
procedures  is  in  erouos  of  three.  This  allows  the 
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^isure  22,  Packet_Handler  Module 
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confirm  synchronization  when  it  is  achieved. 

Packet  transfer  of  command  packets  occurs  one  at 
a  time.  The  reason  for  this  is  that  each  command  packet  must 
he  acted  uuon  in  a  synchronous  manner.  Data  packet  read 
ahead  and  write  behind  is  permitted  to  increase  the  transfer 
rate  of  data  packets.  The  number  of  packets  that  are  allowed 


to  be  sent  or  stored  depends  on  the  IC  buffer  size.  The 
Pa cket_Handler  module  is  also  responsible  for  data 
'’enpacketing"  and  "depacketing”  for  the  PSS. 

The  ?k_End_Synr  procedure  is  used  to  synchronize 
packet  transmission.  It  is  explicitly  called  at  I?L  and 
whenever  the  packet  synchronization  is  lost  by  the  Host 
system.  It  is  invoked  implicitly  by  the  PSS  whenever  a 
packet  is  not  able  to  be  decoded  (viz.,  the  packet  type  and 
packet  check-sum  are  incorrect). 

The  ?k_End_Ack  procedure  is  used  to  send 
acknowledgements  to  the  Host  systems.  This  procedure  will 
always  be  called  from  the  IO_Command_Har.dler  module  which 
will  require  the  ?acket_Bandler  module  to  either  acknowledge 
the  Host  with  a  specific  message  or  to  send  some  data 
located  in  a  mail_hox  segment  buffer  10  the  Host. 

The  Pk_End_Send  procedure  is  used  to  transfer 
data  segments  f^om  the  FSS  to  a  Host  system.  This  procedure 
is  called  from  the  File_Handler  module  which  makes  sure  that 
the  correct  data  segment  is  in  process  memory  for  the 
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transfer.  The  segment  number  along  with  the  number  of  bits 
that  are  reauired  to  be  transfered  are  passed  to  this 
procedure  from  the  File_Eandler  module.  This  procedure  then 
transfers  the  segment  until  the  specified  number  of  bits 
have  been  transmitted,  k  success  code  is  returned  when 
action  is  complete. 

The  ?k_Hnd_Store  procedure  works  in  a  manner 
completely  analogous  to  the  ?k_Hnd_Bead  procedure. 


Ill 


CONCLUSIONS 


A  .  STATUS  0?  RrST’  VHCF 

This  design  applies  state  of  the  art  software  and 
hardware  to  solve  the  secure  multilevel  computer  problem  in 
a  file  storage  system.  It.  presents  an  inexpensive  but  highly 
powerful  design  for  a  system  based  on  a  micro-computer  but 
not  restricted  tc  a  micro-computer  environment,  i>e»,  there 
is  no  restictior  on  the  type  of  Host  computer  system 
serviced  by  the  FSS.  Implementation  of  this  design  on  Z822C 
hardware  alone  with  the  analysis  of  FSS  design  parameters 
(Appendix  A)  are  tas^s  left  to  be  done. 

There  are  two  major  classes  of  applications  for  the  FSS. 

One  application  uses  the  FSS  as  a  system  file  system  (e.g., 

for  distributed  micros).  This  implies  that  the  total  system 
/ 

is  multilevel  secure  with  only  or.e  secure  component  (vi?. . , 
the  Kernel).  It  must  be  noted,  however,  that  in  this 
configuration,  the  distributed  Hosts  (i.e.,  the  micros)  have 
no  autonomous  life. 

The  other  class  of  applications,  involves  using  the  FSS 
as  one  element  of  a  net  of  autonomous  Host  systems.  In  this 
configuration,  the  FSS  provides  facilities  for  controlled 
data  sharing  and  communication. 

An  obvious  direct  application  of  the  FSS,  is  for 
shipboard  use  (e.g.,  for  the  5NAP-II  system  [Smith])  or  for 
use  at  other  installations  where  data  would  be 
efficiently  used  if  controlled  data  sharing  we^e  allowed 
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A  major  design  choi 

eg  of  the 

FSS 

which 

allowed  the 

Kernel  to  be  kept 

small  (and 

the 

refore 

more  easily 

verifiable',  was  the 

el i mi na  t i on 

of 

the 

discretionary 

security  from  the  Kernel  domain  to  the  Supervisor  domain. 
The  implication  of  this  choice  is  that  each  Host  system  is 
responsible  for  its  own  discretionary  security!  not  an 
unreasonable  recuest  or  design  choice. 

The  next  major  task  to  be  accomplished  in  this  project 
is  FSS  implementation.  This  will  not  be  a  trival  task,  but 
it  is  felt  that  the  designs  oresentea  in  this  thesis  and  the 
companion  work  done  by  Coleman  provide  a  solid  basis. 

?.  FOLLOW  ON  WORK 

This  design  is  a  specific  implementation  of  one  member 
of  a  family  cf  operating  systems  based  on  the  Security 
Kernel  concept,  discussed  by  O'Connell  and  Richardson 
[0 'Connell] .  There  are  obvious  areas  that  this  design  could 
be  expanded  and  generalized!  areas  that  should  be  examined 
after  a  successful  first  implementation.  Some  of  these  areas 
are : 


’operator’  terminal  interface  funcions 
expanded  H^st  commands 

map  of  different  "user*  names  in  different  Hosts  to  a 
common  "user"  in  the  T8S 

data  compaction  onto  secondary  storage 

multilevel  costs 

moving  discretionary  security  into  the  Kernel  domain 
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dynamic  process  creation/deleti on . 

These  ere  just  3  few  cf  the  many  possible  areas  for 
expansion  that  my  Id  he  explored.  Ore  area  not  mentioned  ir 
the  list  but  an  area  that  should  be  looked  at  during  the 
initial  iirulen'ertaticn  is  for  a  way  to  prevent  the 
Supervisor  from  suffering  a  ’segment  fault*.  The  oresent 
arrangement ,  with  a  faul*  handler,  is  not  efficient  or 
’elegant*.  Since  the  deletion  of  a  segment  is  controlled  by 
the  Delete_Se£nmr t  Kernel  primitive,  a  method  of  leaving  an 
orphan*  copy  ir.  process  memory  would  eliminate  the  fault 
condition.  The  only  operation  that  would  he  defined  on  this 
’orphan*  would  be  a  Delete  Segment  command  by  a  crocess  to 
remove  i*  from  process  memory.  After  it  had  been  deleted  by 
all  processes,  the  cony  could  be  destroyed.  A  variation  of 
this  scheme  would,  upon  a  Kernel  Svap_In  call,  swap  into 
process  memory  a  per — process  copy  of  the  desired  segment. 
Svap_Cut  would  be  used  to  free  process  memory. 
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C_;  3 1  STOnF  T I LT  TTIT'l  3F  (''••3  HK3  3 TO*J  ?  -■  1  -  v 
C*s"  H-*D_»rx  '7MwC^r_HSD_3TiD_  SCL* 

fASs  ATT  ACL  FMTFT  THEN  CHT  EMP  AFI  ACL 
CASE  BFLETF  ®CL  F’iT5’:  ,?KFN-?f’*  C^"j  F \' DiL*1^ 
f*ssp  a-coHT  r*viTi ~  i^ORT  ~  “ 


ELSE 


FAIL  5CT.F5C.IMST  :=  'CK  PCS? 
v*  TL  ?OT.«SC .?s?HNsv-  s*"KULI 
KAIL  301. WSG.FI LF  Sir?  :=  MULL 


FAIL  50X.FSG.SL-CC _CrtSF  EfRCr.  CODE  (ILLEG'-L  C^?> 
t  :=~  Gi?TTr'7?Ti?  .TTrEFT  (VPIL  -OX, 


GATEEFF???. AT? AMCE  (MAIL  BOX,  C) 
C-ATFSFFPFF.  *¥AIT  f^sil  BOX,  C,  (t+2)} 


•n  m 


INTERNAL 
MSG  *  m 


FM  CMD  HND  DELETE  FILS  PROCEDURE 
ENTRY 

MSG  :=  D^Lr?ir_t’I L^ 

DIR  CNTRL  DIRSCTCRY  (MSG 

USFRID 

PATHNfiMr 

NOLL  !file_ty?e! 

NULL  ! access _1 evel ! 

NULL  ! 1 ink ! 

NULL)  !acl_entry! 

! returns  dir  succ  code! 


1  DIR 

.sue 

C_CO 

nv  s  1 

TRUE 

THEN' 

MAIL 

BOX 

.MSG 

.INST 

:=  ACK 

HOST 

MAIL 

POX 

.MSG 

.PATHNAME  := 

'NULL 

MAIL’ 

‘BOX 

.MSG 

.FILE 

_SIZE 

=  NULL 

MAIL* 

BOX 

.MSG 

.SUCC 

CODE  :  = 

=  FILE 

t  :=  GATr'Kiri:’PTR  .TICKET  (MAIL_T0X,  C) 

GATEKEEPER. ADVANCE  (HAIL  PCX T  C) 

GATEKEEPER. ‘WAIT  (MAIL  POX ,  C.  (t+2)) 

*LSS 

MAIL  3CX. MSG. INST  :=  ACK_HOST 
MAIL^ECX  .MSG ,PATHN®MF  :=  NULL 
MAIL~BOX.MSG.EIL*  SIZ*  :=  NULL 

MAIL_BCX.MSO.SUCC~CODE  :  =  ERROR_CODS  ( ri.i_SUCC_CODS ) 
(file  not  found?  write  access  to  directory 
not  oermi tted ! 

t  :=  GATEKEFPER .TICKFT  'MAIL_BCX,  C) 

GATEKFEPF? . 'DV «NCE  (MAIL_50X,  C) 

GATEKEEPER . ‘WAIT  (MAILBOX.  G,  't+2)) 


END  FM  CMD  HND  DELFTF  FILE 


Ff  ,MD_FND_  CPE  ATF_rILE  PROCEDURE 
E  t»Y 

fSG  :=  CREATE_EILE 
DIR  CN'TRL_DI  RECTORY  ( MSG 

USER  ID 

PATHNAME 

EILE_TY?E 

acc^ss_ltvh. 

NULL  !  1 ink ! 

NULL'  ! acl  entry! 


Ireturns  dir  succ  code! 

IF  PIR_SuCC  CODE  =  TRUE 
THEN 

MAIL  POX .MSG. INST  :  =  AOKJIOST 
MAIL"BOX. MSG. PATHNAME  :=  NULL 
MAILBOX. MSG. FILERS IZE  :=  NULL 
MAIL  BOX  .MSO  .SUrr‘_r‘ODi:’  :=  ,pILir__CP.EA?FD 
t  ':--~GATEKSFPHR. TICKET  { MA I L_ BOX,  C) 
GATEKEFPEP . ADVANCE  (MAILBOX,  C) 
GATEKEEPER  .*W* IT  (MAILBOX,  C,  <t+2)) 


ELSS 

MAIL  BOX. MSG .INST  :=  ACK.RCST 
MAIL  "POX .MSG .PATHNAME  t=  NULL 
MAIL'BOX. MSG. FILE  SIZE  :=  NULL 
MAIL“BOX.MSG  .SUCC'CODE  :=  EF?.OF_CODE 


( DIR  SUCC  CODE) 


Idirectory  not  found;  ^rite  access  to  directory 
rot  remitted;  directory  *ull! 
t  :=  5ATSKEFPER. TICKET  (MAIL_30X.  C) 

GATEKEEPER .ADVANCE  (MAIL  POX,  C) 

GATEKEEPER. AWAIT  (MAIL_BCX,  C,  (t-*-2)) 


El 


^ND  EM  C^D  HND_CFEAT1:,_EIL1:' 
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PM  CMD  CR?AT'P  LIN?  PROCEDURE 
ENTRY 

MSG  CBEATEJLINX 
DIU  CNTRL_PT RECTORY  (  MSG 

USSR  ID 

PATHNAME 

NULL  tfile  type! 

NULL  laccess  level! 

LINK 

NULL)  !acl_entr.y! 
!returns  dir  succ_code! 

IE  DIE  SUCC  CODE  =  TRUE 

TPTTNj" 

MAIL  BOX. MSG. INST  :=  ACKJiOS? 

MAIL  ROX. MSG. PATHNAME  NULL 

M»IL  POX  .MSG.'5’ILX’_STZT’  :=  NULL 
MAIL~3CX  .MSG  .SUCC~CCDE  1.1  NK_ CREATED 

t  :=' GATEKEEPER .TICKET  1  MAIL  BOX,  C' 

GATEKEEPER  . &DV  i.NCE  'msJL  POX',  O' 


GATEKEEPER . AW  A  IT  { M A1 L. BOX 


C  *'  t+2) ) 


ELSE 

^AIL  POX. MSG. INST  :=  STJIOST 
MAIL  BOX. MSG. PATHNAME  :=  NULL 
MAIL~BOX.MSO.EILE_SIZE  :=  NULL 

f1AI  L~POX  ,MSG  . SU^C^COD17  ;=  ^RROP^COPE  (  DIR_SUCC_CODE) 
ldirectory  not  f^urd?  write  access  to  directory 
not  permitted;  directory  full! 
t  :=  GATT'KT'rP'pR. TICKET  'MAIL  POX,  C) 

GATEKEEPER. ADVANCF  (M,AIL_BCX7  C) 

GATEKEEPER. AWAIT  ( MAIL  BOX,  C,  (t+2)) 


FM  CMD  READ  FILE  PROCEDURE 
ENTRY 

IF  FI  I,1’  TY?ir  =  FAT® 

THEN 

MSG  :=  READ  FILE 
DIR  CNTRL  DAT*  ! MSG 

USERID- 
PATHN  »MF 

NULL)  I file_cize! 

Ireturns  dir_succ  code,  dir_t>athname,  dir  file_size! 

IF  DIR  SUCC_CODE  =  TRUE 
'pp-p^r 

MAIL„30X .^SG.INST  :=  READ_FILE 
MAIL  BOX  .MSG  .PATHNAME  :=  DI  R_PATHNAME 
MA  IL’  POX  .MSG  .FILr_SIZr  :=  DIR  FILE_SIZS 
MAIL_30X  .MSG  ,SUCC_f’ODF  :  =  NULL 
t  :=  GATEKEEPER  .TICKET  M»IL  BOX ,  C) 

GAT^K^^R  .  »BV®NCr  -^»IL  *0X7  0) 

GATEKEEPER. AWAIT  (MAIL  BDX ,  C,  (t+2)) 

IF  MAIL  BOX. MSG. SUCC  CODE  =  TRUE 
TUFN 

MSG  :=  UPr*TF_READ 
DIR  CNTRL  UPDATE  '■  MSG 

USERID 

PATHNAME) 

•update  will  cot  fail! 

MtT  L  -OX  .N'SG  .INST  :=  ACK_HOST 
MAIL  BOX. MSG. PATH NAME  :=  NULL 
MAIL  BOX. MSG. FILE  SIZE  :*  NULL 
MAILBOX  .MSG. SU^c'  rOD^  *=  RTAD  COm?LFTv 
t  :=  GATEKEEPER .TICKET  (MAIL_R(3X,  C) 

GATEKEEPER. ADVANCE  'MAIL  BOX,  C) 

GATBK^pvp.ayaiT  /M®IL_'cOX,  C) 

ELSE 

MAIL  BOX. MSG. INST  :=  ACK  HOST 
MAIL_?GX .MSG .PAT^NAM*  :=~NULL 
MAIL  BOX. MSG. FILERS I2E  :=  NULL 

MAIL'bOX.  MSG.  SUCC_  .CODE  :=  MAI  l_3CX  .MSG  .SUCC__CODE 
!errbr  code  returned  from  io  process! 

’file  ret  found  by  io  process? 
file  read  aborted  by  write! 
file  read  aborted  by  file  deletion! 
cmd  packet,  received! 
t  :=  GATEKEEPER .TICKET  'MAIL  BOX.  C) 

GATrK'5’'T?'!?R .  SUVA  NO'5'  'MAIL  POXT  C) 

GATEKEEPER .AW® IT  l*kll  5oX,  C,  (t+2)) 

El 

ELSE 

MAIL  BOX. MSG. INST  :=  ®CK_HCST 
MATL~POX .MSG .ptTHN&M^  t=  NULL 
MAIL'BOX. MSG. EILE_S I ZE  :=  NULL 

MAIL“BOX.MSG.SUCC_rODF  :  =  ERROR _ CODE  (D I R_SUCC_COD 
! f i 1 e  not  found! 

read  access  tn  file  cot  permitted! 


1*0 


t  :=  GATErEFPEr .TICKET  (^®IL_30X,  C i 
p  t  n’PKP'P?17'?  .  *  PV *  NCT  /MSILJROX.  C) 

GATEKEEPER . AWAIT  (MAILBOX.  C,  lt+2)) 

FI 

v^SE 

IF  PILE  ”YPV  =  El RECTORY 

*  then 

Mgo  •=  FIR 

PTO  CNTR  L  pi  RECTORY  '•’/SG 

EI--L  USERID 

p&TPN  * M? ) 

MULL  ! fi le_type  ! 

NULL  !access_lev=l ! 
NULL  ? li nk  ! 

NULL)  ! a  cl _ entry! 

^r8 rr ^  d  i  ^  s  u  c  c _ cAd°* 

IF  UI?._SUCCjOPF  =  TBUP 

TH1!N  rrr^Q1 t» 

MAIL  SOX. MSG. INST  :=  6CX_hvS, 
mstt,  POX  .MSG  .PATHN  *MF  s*  NULL 
MAIL  3CX.VSG.FILF_SIZF  rn..PTT 

MAIL~R0X  .MSG  .SUCC  .CODE  :=  DI "  - ~E^-C ?  L‘ 
’dir  data  transfered  fron  dir_buf.er. 

'M«IL.B0X.  e) 

r  iTi’tfPPPPR  .  APV A Nr,ir  'MAILBOX.  C) 
GA^EKE^PER • AWAIT  -MAIL_BOX«  C,  (t+2)) 
EL5P 

Mil L  PCX. M-S3. INST  t=  & Cv _PO S T 

MAI L~BQX . ySG . ?A THN  AME  : =  NULL 

M*  IL'  BOX  .MSS  .FILE  SIZE  K;ulL  ^ 

mWl'pC-X  .MSO  .suco_ropp  ?  =  FRRCR.COPi  1  -'I 

!di rectory  not  f^urd,  _  ,Ho,, 

read  access  to  directory  not  pe.-r.vted. 
t  .  =  c sTPypPpPR .TI rEET  ' MAILBOX. 
gatekeeper .advance  'mail.box,  Cj 

G ATEXEEPEE  .  AW  AIT  'M*n,_BOX.  C  ,  f  -  2)) 

n 

ELSE 

pgQ  PE£D  ENTPY_I) AT* 
t\T P  r’N'TPL  PIE'pr,TORY  '  MSG 
-  ‘  -  USERID 

pathname 

null  ! file _ type! 

NULL  !access_level ! 
NULL  !lir’< ! 

NULL'  !acl_er.try! 

’returns  d ir_succ_code! 

IF  DIP_SUCC_CO'DE  =  T?Ui 

qiTJt'M 

MAIL  BOX. MSG. INST  ACE  HOST 
M*IL  eox. MSG. PATHNAME  :=  Nl^L 
MaTL  POX  .MS-G .TI LE_STZr  :=  NULL  ^ 

MAILBOX. MSG. SUCC_CODE  :  =  EN i ~Y_n5Ai;_u, 


R  succ_ 


^MFLETE 


' e-'try  data  transfered  from  dir_buffer* 
acknowledgement  sent! 
t  :=  GATEKEEPER  .TICKET  'MAIL_BOX,  C) 

GATEKEEPER.  ADV#*fCF  'MAIL_8CX,  C) 

GATEKEEPER  .AWAIT  'MAI1JPOX,  0,  (t+2)) 

PLSE 

^OX  .MSG . INST  ;  =  A.CK_HOS! 

MAIL  BOX. MSG. PATHNAME  :=  NULL 
MAIL  BOX. MSG. PILE  SIZE  :=  NULL 

M»IL_?OX.MSG.SUCC~COP*'  !=  ERROR _CODF  (EIR_SUCC_COPE) 
!file  n^i  found?  read  access  to  file  not  permitted! 
t  :=  GATEKEEPER .TICKET  (MsIL_BOXt  C) 
n  jwpTif-t'-pp'spp st>V 4 NGr  'MAIL  ^0X7  C) 

GATEKEEPER. AWAIT  f MAIL  BOX,  C,  (t+2)) 

El 

El 

El 

END  FM;  CMD  HND  HEAD  FILE 
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FM_CMD_HND  STORE  FILE  PRCOEDUhE 
ENTRY 

MSG  :=  STOK”!!** 

DIR_CNTRL  DATA  (MSG 

USERID 

pgipU^&MTT 

FILE_S IZE) 

(returns  dir  pathname?  dir  succ_ccde! 

I?  DIR_SUCC_?b1'1'  =  TRUE 
THEN 

MAIL  BOX. MSG. INST  :=  STORE  FILE 
M*.IL~FOX  .MSG  ,P*TnNA MP  •=  l  PATHNAME 
MAIL~BOX  .MSG  .EILE_S  IZE  :  IIE__SIZE 

M  A I L  _BO  X . MS  G . S  UC  C_C  ODE  NULL 

t  :  =  GAT^'K^P^R . TICKET  'MAIL  BOX,  0) 

G  A TE KEEPER  .  ADV A NCF  ( M  A I L_ BOX  7  C ) 

GATEKEEPER . SW 4 IT  (MAIL  BOX,  C,  -t+2)) 

IF  M«IL  BOX  .MSG . SUCC_r'ODr  =  TRUT 
TEEN  " 

MSG  :=  UPDATE  STOKE 
T)jp  fNTRL  UPDiTT  'MSG 
‘  '  "  “  USERID 

PATHNAME' 

lupdate  V7 ill  not  fail! 

MAIL  BOX. MSG. INST  :  =  ACK_HCST 
MAILBOX .MSG .PATHNAME  :=  NULL 
M»IL  BOX  .MSG  .?TLF_STZT’  :=  NULL 
MA.IL_BOX  ,MSG.SUCC_CCDF  :=  STORE  COMPLETE 
t  :=~GA.TEKEE?E~  .TICKET  (MAIL_30X,  G) 

GATEKEEPER . ADVANCE  'msil^OX,  C) 

GATEKEEPER. AWAIT  (MAIL_3CX,  C,  (t+2)) 

ELSE 

MA IL_BOX  .MLG .INST  :=  ACE  *OST 
MAIL  BOX. MSG. PATHNAME  :  =  NULL 
MAIL  BOX .MSG .FILE_STZE  :=  NULL 

MAILlBCX.MSG.SUCC_COry  :=  MAIL_30X .MSG .SUCC_CODE 
!error  returned  from  io  process? 

cmd  packet  received?  imorcoer  number  of  data  packets! 
t  :=  GATEKEEPER .TICKET  (MAIL_BOX,  C) 

GATEKEEPER. ADVANCE  'MAILJBOX.  C) 

GATEK^EP^R  .  *W»  IT  (M»IL_?OX,  C,  (t+2)) 

El 

ELSE 

MAIL_ROX .MSG. INST  :=  A CKHOST 
MAIL  BOX. MSG. PATHNAME  :  =  NULL 
MAIL"30X.MSG.EILE_SIZE  :=  NULL 

MAIL  BOX. MSG. SUCC_0CDE  :  =  vRROR_CODE  ( DIR_SUCC_C0BE) 

I f i 1 e  «ot  ncurd?  write  access  to  file  not  permitted! 
t  :=■  GATEKEEPER. TICKET  'MAIL_ECX,  C) 

GATEKEEPER .  *DV  »Np1?  (M*IL_POX,  r  ^ 

GATEKEEPER. AWAIT  (KAlVpCX,  C,  (t+2)) 

FI 

END  EM  CMD_HND_ST0R^_EILF 
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FM_CMD  HMD  RFID  *CL  PRO^DUR? 

ENTRY 

MSG  :=  READ  «CL 
DIR_CN'TRI_PIRrf'TORY  t  MSG 

USERID 

PATHNAME 

NULL  .'file  type! 

NULL  !access  level! 

NULL  'link! 

NULL^  !acl_entry! 

{returns  dir  succ  rode! 

IF  DIR  SUCC  CODS  =  TRUE 

Tr4?N  ~ 

MAIL  BOX. MSG. INST  :=  ACK_HOST 
MAIL  BOX .MSG .? ATHNAMF  :=  NULL 
MAIL~?OX .MSG .FILE  SIZ^  t  =  NULL 
MAIL_30X  .MSG . SUCC~COPF  :=  ACL_?.SAD_CCM?LETS 
!acl  data  transfered  f ro^  acl_buffir; 
host  acknowledgement  sent! 
t  GA'TEKS^PE"  .TICKET  'MAIL  BOX,  C) 

GATEKEEPER . '^VANCE  (M*IL  BOXT  C) 

G  A  TrX"pFPrR  .  AV/  *  I T  (MAILBOX,  O,  ft+2)) 

ELS  E 

MAIL  BOX. MSG. INST  :=  '.OK  POST 
MAIL  ^OX .MSG .PATHNAME  :=\NULL 
VA IL  BOX. MSG. FILE  SIZE  :=  NULL 

MAIL"PCX.MSG.SUCC~C0DE  :=  F?ROF_CODF  (DI R,SUCC_CODE ) 
ffile  not  found;  read  access  to  directory  file 
not  po^Tii  t  +  ed  ! 

t  :=  GATEKEFPE?. TICKET  'MAIL_BOX,  C) 
GA.TtT"I'PTR.sPV*Nr,v  (%isiL  POX,  C) 

GATEKEEPER. AVA IT  (MAIL  BOX,  C.  (t+2)) 

FI 

■^ND  FM  CMD  FND  ?FaP  A  EL 
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?M_CMD_H'4D_AT>T)_^I^NTRY  PROCFTOr* 

^MSS  *• r  ADD,  a.CL_INT?Y 
dir_cktrl_di?.^tori 

pathname 
MU1L  '.file  type! 

NULL  ! access  level! 

NULL  llit'V’! 
a-"L  ^NTP.Y ) 

!  returns  dir_succ„co^e! 

IP  PIP  SUCC_CCDS  =  Tr.Li 

VAIL  BOX  .MSG .INST  :=  ACY  HOST 
vtIL“BOX  .MSG .PaTKNAMi  t=  I  JL:_ 
m_sjl  -OX.MSO.HILT„SIX- 
vftIL_30X .MSS .SUCC_CCD? 

V  .I" GftTPX'.HPHF.TICYFT 
n  1ipTV'5'T,prpi  .  tpv  R  Nf*"  ^  &  I  u_r  CX  t 

GATF.X  B;  ?tR  .  AW  A I T  ( K  A I  L_  BOX  , 

HIS  u"30X  -MSG  <|JJ, 

;:  risfe  ror-  oih_socc.com 

c«s  t5  Urs-cHry  lot 
Ifile  rot  frurdt  , 

*  permitted 4  acl.entry  uool 

tP!=  o.aT^TTp^.TICX’T  MM._-OX,  -> 

GATEKHEPVR.ABVANCH  (^-TI_?OX,  -> 

G  tTEKSFPFF  .  *W  AIT  (F.AIj..-OX(  L. 

PN D  FM _CMD _H  ND  _  A  DP  _  A  0 1_EK  T R  Y 


=  N  U  ji 

-  ftPT 

—  r.Oy 

v  HT 

i 


N  i  " 


A  i 


pnp. 


BOX. 


;) 


V  1 


It 


A  '  ' 

rtL  I  ) 


ENTRY 

MS {J  j=  t-cnpT 

DIF  CVTF.L  UPDATE  f MSG 


USFRI^ 

PATRN Avt ) 

?  3 1  n  c^i  *■  n  fi»pp  tpr^^prSry  ^  i  1  e  ! 

MAIL  -OX  .MS'! . I NST  :=  ACE  "OST 
HA I L~30X . MSG . ? ATHN A^v  : -_MULL 
k f IL~ BOX* MS  0 .PI LF  SIZE  :  =  NULL 

mjjt  mSG.SUG?-  f,nT‘-'r  *=  r*M-  i-=Qo-> r  t 


I C  COMMA  S'  r.  HA  N  DLFE  MODULp 
EXTERNAL 


py  HN'D  STORE  PROr-nUKf  '-s?"  - 

SIZE 

RETURNS  ( PESUCC  COD? 

?K  HMD  SEND  ?ROf,T’f,'IR'r  ( S”T  - 

SIZE 

RETURNS  ' ?K_SUCC_"OPF 
PE  HMD  ACE  HOST  PROCEDURE  «'MSD 


LVoRD  ! nunbt. r  cf  bits! 


LWO-:D)  ! rubber  cf  bits! 

SVfp  \ 


PILE  tJND  SEN-"  EIL~  ?ROCT’T^URT’ 
RETURNS  '?ILS_SUOC_COD? 

?ILE^KND_  STORE-  PILE  PEOCEPUE 
RETURNS  «FILE_SUCC_COrE 

INTERN AL 


P  £*1*^  M  t  MP 


T 


10  CMC  END  PROr^I!?,^ 

ENTRY  “ 

t  :=  TICKET  (MAI L_ -OX .  O' 

AW®  IT  v®  II  -OX.  »*,  ft*U' 

DO 

IF  M 5 IL^BOX .MSO . INST 

r«cT  ;Tjr\  f*VTi  TOTHJ  T?»  Utn  PT*T*.  pMTV 

ace  Host  then  ?k"hnd"a:>:  host 


cas- 


•'V?I L  30X . MS"  . 3UCCC0DF) 


CI$t  S"NO  FT  L-  TI Rt  F’ T.T 


(VAIL  *30X7  VSG .  PATHS' AM 
! vs 1L30X . MS 5 .FILE  SI 


r*5T  stgf~  t*T t 


T  ?T| 


P0Y 


t  :=  Tier??  #V*T 
AD Vr.NCF  'FHL^BOX,  C) 

;  v  ?  ;  v  *  T  7  pat  A  f  r  ♦ 

*  "  ■  J  -  ‘  V-.  t  t  5  -  "  * 

CD 

END  10  CM.D_END 

END  10  COMv*.NT'  -  ‘NFL"? 


s "AIL  RCXTmSG. PATHNAME 

v  l  t  T  av  uC"  ■"  r  -  ^  T  *>"  ' 

l  r:  I  __  UUA  .hV**  .  r  1  I  } 

n  \ 
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